67: ILLEGAL SYSTEM T OR S

[jkotlinski]

While developing in Vice, I started to get this drive error:
67: ILLEGAL SYSTEM T OR S

Commodore 1541 Users Guide writes: "This special error message indicates an illegal system track or block"

I cannot remember ever seeing it before. Do you have any idea what might cause it?

EDIT: I can answer my own question. When enabling True Drive Emulation, the error changed to "72: DISK FULL". Disk space is slowly starting to become a serious concern.

[Whammo]

Yep.
Inside Commodore Dos says,
"By the way, what happens when you try to save to a full disk? Error 72, DISK FULL
right? Would you believe error 67, ILLEGAL TRACK OR SECTOR,36,01? Track 36?
That's right. An error 72 only occurs during normal write mode (i.e., not a direct-access
write) where at least 1 free block exists at the outset or the directory is at its physical
limit, i.e., 144 active file entries."

[Whammo]

Oh, and Validate the disk.

[lonetech]

The immediate question has been answered quite nicely by Whammo, but it brought to mind a few comments.

While emulating you don't have to stick to the 1541's limits. If you just need some more space, use a d81 image instead of d64; the 1581 stores 800k rather than 180k.

I noticed the deploy step, precompiling Forth sources inside of vice, loads the bootstrap durexforth from the same disk it's later written to. This not only uses more space, it leads to fragmentation, as the new image is larger and placed later on disk. This leads to slightly longer load times on real hardware. A variety of workarounds are possible, but the easiest is to just copy files onto a new disk image in the correct order. I figure this level of polish is of interest considering the pretty directory with dividers, version tags etc.

One of the thoughts that popped into my head was of a sort of overlay system. Consider if we used HERE and LATEST from a marker, such as ---editor--- or ---modules---. We can then store a program file with mHERE:HERE, LATEST:mLATEST, mLATEST-LATEST. Then, rather than recompile v, we could load that image onto HERE, back up one word to find its dictionary size, move its dictionary image onto our dictionary and advance HERE. Maybe store some sort of checksum (e.g. HERE value+system version) just to avoid linking in an incompatible image.

I've also been thinking about swapping in portions. This could be useful e.g. for a cartridge version of V that doesn't consume as much main RAM. The basic idea is, set HERE to compile to where the program will be stored (e.g. $9000, halfway through low cartridge ROM), and have the entry point routine left in the main dictionary enable the ROM before jumping there (the dictionary won't be needed while inside v anyway). It wouldn't be as convenient for core words because it would mean the overlapping RAM couldn't be used from plain Forth code. But combined with a cartridge decoder, REU or similar, we could get a lot more working space. By the time a cartridge durexForth v consumes under 20 bytes of RAM rather than 4679, perhaps the marker ---editor--- itself isn't needed.

As Whammo has suggested, such overlays could also be placed in the RAM that shadows I/O. This would complicate v a bit, as the main event loop would need to sit outside to reenable I/Os and interrupts (as volksForth large C16 does per #351), but perhaps some more self contained facilities like vocabulary switching or indexing would sit nicely there.

Feels like time for another crazy proof of concept. How about a module that REU-accelerates move and swaps v in and out?

[jkotlinski]

It would be nice to have REU support as an optionally included module, similar to how cc65 does it.

[polluks]

By the way vbcc has also some nice banking support, see 11.8
http://www.ibaug.de/vbcc/doc/vbcc.pdf

[Whammo]

I've been playing with RAMDOS for the REU on it's utility disc.
Once you have installed RAMDOS and copied over the requisite files,
it seems quite happy to boot up durexForth and operate perfectly as unit 10.
Perfectly faster at everything disk related. I highly recommend the experience.

[Whammo]

The 'dos interface page' at cf00-cfff uses the last page of color, so gfxdemo munches RAMDOS.
It's moveable to anywhere not under ROM, so it may be possible to move BASIC to $0900,
install RAMDOS with the interface page to $0800,load durexForth- now at $0900.

It could be interesting to run durexForth so relocated, even without an REU.

[Whammo]

Nope- the SYS call points to the wrong place when basic is moved, and etc.