[Coco] I fixed the goddamn PCLEAR 0 bug.

[Juan Castro]

(Sending again because it hadn't gone to the ist, just for you)

About PCLEAR 0, I think it's more oversight than bug.

What I did is a souped-up version of DECB (or, more exactly, of HDB-DOS)
that's 16KB, so I have room for all kinds of shenanigans. So far, I used 5K
of the extra 8K available. Take a look at README-16K.txt.

SUMMARY OF CHANGES:

- All CoCo 3 tokens are recognized, so a CoCo 3 BASIC program will not be
  garbled upon loading
- 51x24 and 64x24 text modes in PMODE 4, switchable with WIDTH command
  - Requires at least 4 graphics pages (6K) PCLEARed; forces PMODE 4
  - PRINT@ works as expected, with the maximum position being 1223 in 51x24
    mode and 1535 in 64x24 mode
  - The charset defined in ROM is ISO-8859-15, although it's possible to
    redefine it with HSET MEM COPY and HPOINT(5) (see below)
- LOCATE works as expected
  - Works in the 32x16 screen too, unlike the CoCo 3
- Support for BUTTON function including 2nd joystick button (requires
internal
  wiring; testers welcome)
- DIR output uses available screen width
- TIMERL function similar to TIMER but wraps at 2^32 (2 years, 98.5 days)
- TIMER FOR N waits N seconds (N may be a fraction: TIMER FOR 1.5 waits
1.5s)
- HSET MEM COPY moves BASIC to RAM in 64KB machines; HSET MEM and HRESET MEM
  switch to RAM and ROM respectively
- HSET COLOR 1 sets text screen to orange; HSET COLOR 0 sets it back to
green.
- HPOINT gives you some system information:
  - HPOINT(0) returns the CPU model (6809 or 6309)
  - HPOINT(1) is planned to return whether the 6309 is running in Native
Mode.
    (Currently, always returns zero.)
  - HPOINT(2) returns whether BASIC is running from RAM (see HSET MEM)
  - HPOINT(3) returns the address of a useful data area for manipulating the
    new graphics-text mode (cursor blink, shape etc); see new file
    cocoroms/rom16kvars.asm
  - HPOINT(4) returns the frequency of timer interrupts - 50 for PAL, 60 for
    NTSC - this is the value you need to divide TIMER/TIMERL by to get
seconds
  - HPOINT(5) returns the address of the graphics-mode text font - 896 bytes
    for the 51-column version, followed by another 896 bytes for the "thin"
    (64-column) version
- BASIC printer output redirected to DriveWire virtual printer
(experimental),
  now with a flag in the aforementioned data area to disable redirection,
  still with no BASIC interface to control it
- Accepts binary constants with &B, just like &H and &O
  - Also, these notations can yield values up to 2^32-1
  - Ancient bug in &O (accepted 8 as a digit) fixed
- Conversely, HEX$ now accepts values up to 2^32-1
- ONERR, ERNO, and ERLIN work as expected
  - Differently from the CoCo 3, ERNO and ERLIN can be examined in direct
mode
    after the BASIC program ends.
- LPEEK and LPOKE work like PEEK and POKE but arguments are 16-bit unsigned
  integers, i.e., they affect addresses A and A+1. Example: LPEEK(&H68)
  returns the line number of the running BASIC program -- previously you
needed
  to use 256*PEEK(&H68)+PEEK(&H69).
  - Additionally, both have now a block copy syntax: LPEEK$(A,N) returns a
    string with N characters with a copy of memory at address A. Likewise,
    LPOKE A,X$ pokes all characters of X$ consecutively starting at address
A.
- GOTO X may be used as an expression; it simply returns X. Useful for
  self-documenting programs that can be renumbered. Example:
  - 10 PRINT"TO CHANGE THE FUNCTION, EDIT LINE";GOTO 500
- Allows PCLEAR 0 for more RAM - instigated by an article by Allen Huffman:

https://subethasoftware.com/2015/01/16/pclear-0-to-get-more-coco-basic-memory
  Requires PMODE 0. You should not, under any circumstances, do anything
with
  graphics while in this mode or your BASIC program will be mercilessly
  clobbered.


Juan Castro
Enviado do meu Olivetti Programma 101
http://retropolis.com.br


Em sex., 1 de ago. de 2025 às 19:07, Allen Huffman <alsplace at pobox.com>
escreveu:

> For those now following along — go watch that video on Juan’s dropbox.
> It’s quite cool.
>
> On Aug 1, 2025, at 4:59 PM, Juan Castro via Coco <coco at maltedmedia.com>
> wrote:
>
> That particular check is standard in ECB. You can't PMODE into something
> for which you haven't PCLEARed enough, and you can't PCLEAR less than the
> current PMODE needs. My new checks are only for the new things: WIDTH and
> PCLEAR 0.
>
>
> If I ever knew this, I forgot.
>
> I guess I was unaware you could just do:
>
> PMODE 0
>
> …without the “,X” number after it.
>
> Now that you have been in that code, is PCLEAR 0 a bug/oversight, do you
> think?
>
> WIDTH 51 is surprising to me. Did you implement any other widths like that?
>
>
> 51 (5px wide char cell) and 64 (4px wide char cell).
>
>
> That is very cool. 16K rom, I suppose, to fit the font data? How does that
> work? CB was 8K, ECB was another 8K, and DECB was a third 8K. I suppose
> that means there is 8K left at the end of that 32K, minus the I/O area (256
> bytes?).
>
> Or am I just remembering nonsense?
>
> — Allen
>
>
>