I'm working up some tape I/O routines for my Forth virtual memory implementation, and I ran across this issue.

http://www.zimmers.net/anonftp/pub/cbm/ ... t/d/petdis

The specifically annoying thing is at $F940, that STA $10 instruction.

$10 is an address which is described as "unused - carried over from teletype" in all the literature. Which happens to be in the middle of my data stack. :(

A grep of the disassembly reveals that $10 is referenced exactly 19 times, which would be bad news. But the good news is that 18 of these 19 times are in the BASIC, so I really don't care. The bad news is It only gets written to by the kernel ROM in exactly one place, $F940. Then the really bad news is that a zero gets written to this address every time the STOP key is scanned for and pressed by the user, e.g. during a long operation or cassette I/O

So I fired up the excellent vice xpet and set a watchpoint and a breakpoint to verify that this is true. Sadly, it is probably going to hose my stack.
(C:$e0bf) break
No breakpoints are set
(C:$e0bf) w 10
WATCH: 1 C:$0010 (Stop on load store)
(C:$e0bf) break f940
BREAK: 2 C:$f940 (Stop on exec)
(C:$e0bf) x

Does anyone here familiar with the PET have any ideas on how to work around this problem?

Thanks,
Charlie

Where does your Forth data stack start? Or to ask it another way, how many cells would it take to reach that address? The amount of stack space needed is far less than most people realize.

_________________
http://WilsonMinesCo.com/ lots of 6502 resources
The "second front page" is http://wilsonminesco.com/links.html .
What's an additional VIA among friends, anyhow?

https://github.com/chitselb/pettil/blob ... ttil16.a65
https://github.com/chitselb/pettil/blob ... weet16.a65


Before finding this problem, the stack was from $00 - $3A (low bytes) and from $3B - $75 (high bytes). So 59 stack words. But in development I use $00 - $2F and $30 - $5F because it's much easier to line things up when reading a hex dump. I split the stack and put the NEXT routine on the zero page and do all kinds of other weird things for speed and memory. Like overlapping the SWEET16 registers on the same 16 bytes of zero page where TOS...N...UP...ZI... live. It gets a little complicated.

After posting this and screaming loudly into the night, I may have come up with a decent workaround. I'll just move things around in z.p. avoid the $10 location

Before:


After:


So pressing STOP will now only potentially hose part of the "N" scratch area or R8 in SWEET16, vs. some random stack effects. Much less likely to cause trouble.

From my own tests, it looks like I have never used more than about 20% of ZP for the data stack-- although compiling a CASE statement with a ton of cases might prove me wrong. When I tested how much I was using, I filled the 6502 stack area with a constant value (maybe it was 00-- I don't remember), ran a heavy-ish application with all the interrupts going too, did compiling, assembling, and interpreting while running other things in the background on interrupts, and after awhile looked to see how much of the stack area had been written on. It was less than 20% of each of page 1 (return stack) and page 0 (data stack). This was in Forth, which makes heavy use of the stacks. The IRQ interrupt handlers were in Forth too, although the software RTC (run off a timer on NMI) was in assembly language.

59 stack words would be a little over 20%, but having something storing at $10 could be a problem even if you didn't try to split high and low byte spaces.

_________________
http://WilsonMinesCo.com/ lots of 6502 resources
The "second front page" is http://wilsonminesco.com/links.html .
What's an additional VIA among friends, anyhow?

Ok. I fixed the "spurious writes to $10" problem by juggling my things around on zero page, but now I'm encountering something that seems to be even worse

http://www.zimmers.net/anonftp/pub/cbm/ ... t/d/petdis

There's a table of vectors


which gets called from various places

and that's what sets up the different modes of tape operation for leader tone, reading, writing, and one of these vectors is the E455 standard IRQ, which updates the jiffy clock and polls the keyboard.


That last JMP $B7C6 is an absolute disaster. From what I can tell just by examining the ROM code, it will plop me out of Forth to a BASIC prompt if the user hits STOP during tape i/o, but the zero page will be totally unprepared to operate in BASIC. I never want this to happen. The only workaround I can see at this point is to use what subroutines I can, but I still will have to clone a whole bunch of tape ROM code into precious RAM. Any other suggestions or pointers to prior art will be greatly appreciated.

Thanks,
Charlie

Charlie,

How open are you to the possibility of burning your own EPROMs with the appropriately modified code? Maybe even a 'piggy-back' modification with an external means of switching between your EPROM and the original ROM chip selects. I am aware of the added danger of digging around inside a 30+ year old computer, but that would probably be my method of dealing with the situation. On the C64, it would be a non-issue, since it has shadow RAM ready to go just for that purpose, albeit with a bit of extra boot time to load and configure your environment.

Mike

The goal here is to have something other people can run on their PETs, so burning ROM isn't really viable.

For myself, I run the vice emulator already, where 'burning EPROM' is a simple matter of patching a file. On my live hardware, I have Bitfixer's PETvet which gives me similar capabilities. http://www.flickr.com/photos/chitselb/s ... 696682160/

I'm initially targeting the 4.0 ROM but it should be a straightforward port to the "version 2" or "version 3" or "upgrade" ROMs (what is the preferred name for this? The ROM with the WAIT 6502,n easter egg). The Original 1.0 ROM will be more of a challenge, as it seems to lack contiguous chunks of zero page that the kernel doesn't use, and possibly because of some bugs.

Ah ... understood! In that case, I would simply stay away from zero-page as much as possible, and put up with the resultant slight inefficiencies in code size and speed. For example, both of your Forth stacks should easily be able to co-exist in page 1.

Mike

Hi chitselb
I don't quite see why you can't avoid using a single address in zero page: if you leave SWEET16 unmodified then R8 is unusable, which is mildly inconvenient, but why can't you modify SWEET16's zp usage as well as your Forth's usage to avoid this single address?
Cheers
Ed

That would be only slightly more practical than having the '02 skip over a byte in the hardware stack space.

_________________
http://WilsonMinesCo.com/ lots of 6502 resources
The "second front page" is http://wilsonminesco.com/links.html .
What's an additional VIA among friends, anyhow?

Hmm, I would never propose that contiguous parts of zero page should skip over a byte, but this design seems to have just one pair of contiguous parts, which aren't large, and location &10 is rather near one end of zero page. So I still don't get it - I must be missing something. To simplify: ignore the first 17 bytes of zp completely, start your allocations at &11, and there's no problem.

I wrote:

which is a mistake. I was thinking 59 bytes, not 59 16-bit cells (which would be 46% of ZP. 59 bytes might be enough ZP data-stack space; but even if you start at address $75, you can get quite a bit more than the 59 without dipping down all they way to address $10, regardless of whether or not you split high byte from low, like chitselb is doing. Since it's a stack though, skipping over a byte is a problem since you want to efficiently do DEX, STA ZP,X for example, and not have to watch for when you get to the byte that must be skipped. X, the data-stack pointer, will be constantly going up and down. It would take away a lot of efficiency if you had to constantly follow the INX or DEX with a CPX #$10, BNE__, INX/DEX. In fact, it gets worse when you want to access the third cell for example, and would have to see if you're reaching past that forbidden byte address. The more I think about it, the more I have to say that taking a byte out of the middle of it is out of the question.

Mike suggested putting the stack somewhere besides ZP. This is normally highly impractical, because of the need for the addressing modes that are available only in ZP. chitselb is trying a model having the top stack cell in a non-indexed pair of ZP bytes though, like putting it in a processor register in a processor that has more of them, meaning that he won't be doing STA(ZP,X) for example (which he can't do anyway with the stack high- and low-byte areas separate, since it means the high byte does not immediately follow the low byte to get a complete address). I don't think it's any more efficient doing it that way, but I'm all for experimenting and getting some actual performance numbers to compare.

We normally start the data stack at the high addresses and go down, like the hardware return stack does. Just as this makes it more intuitive to do for example TSX, LDA 104,X to read the 4th hardware stack byte (regardless of the depth of the stack), it also makes it more intuitive to address things on the data stack in ZP.

_________________
http://WilsonMinesCo.com/ lots of 6502 resources
The "second front page" is http://wilsonminesco.com/links.html .
What's an additional VIA among friends, anyhow?

I completely don't understand! The bad byte is at location &10, right near one end of zp, and not much of zp is being used for the forth stack. Why even consider the need to skip over a bad byte, when it's so easy to place your data elsewhere?
Edit: elsewhere in zp, of course.

He's looking for a robust environment, without having to clone any routines that dump to BASIC as part of their natural operation, because BASIC would be quite ill-prepared to operate with zero-page in 'Forth'-mode. We're not talking about one address, but more like dozens.

My idea to put the data stack in page one would cause a performance hit, but then only the user area would need a few contiguous zp addresses for indirection, and the BASIC GETBYT routine could be wedged to return him to Forth before much (in any) damage could be done from the READY prompt, should he find himself dropped there.


Mike

Edit: I missed the part about TOS in zp. That would lessen the burden somewhat:

Ah, thanks, I see. Having successful avoiding reusing &10, the problem is that one of the IRQ handlers detects STOP on the keyboard directly, and jumps into BASIC. Although the IRQ is vectored through RAM, that RAM pointer is updated in the tape-handling routines. So the puzzle is to repair the vector or avoid setting it... without duplicating too much of the ROM code.