After some years of on and off tinkering, I finally finished my Applesoft upgrade. The Cassette commands have been replaced with more useful commands.
Specifically, SHLOAD is now TIMER=, a time delay routine borrowed from
from Beneath Applesoft. LOAD is now SWAP, from Beagle Basic. SAVE is now ELSE, also from Beagle Basic. Store is now UNTIL, and RECALL is now
REPEAT both from issue 82.11 of Apple-Assembly Lines.
Where the code goes was much more complicated. And to avoid breaking
Program Writer in interesting ways, I had to keep the command names the
same length. So some swapping of where the command addresses go did occur.
Specifically; The much reduced code space for SHLOAD in the enhanced IIe
ROM is now taken up by a little readkey routine called by USR. The USR
vector was left untouched in case I wanted to use it for something else,
but two pokes to set the address to F775 and USR returns a keyboard code,
and clears the strobe as it leaves.
SWAP ended up unchanged from the Beagle Basic version, in the Load Space. ELSE (formerly SAVE) got repointed to a hole hollowed out of ColdStart.
The Coldstart routine contained a great deal of cruft from the days of cassette Applesoft, including a routine to test RAM. As every Apple I
have has 64k on the motherboard, this is pointless. So HIMEM gets set to $9600 and we are done with it.
The SAVE space is filled with the TIMER= routine. The STORE space holds
the RPOP, the third part of the REPEAT-UNTIL call. RPOP can not be called directly, not that you should (But you could CALL it from Applesoft). The beginning of REPEAT, (formerly RECALL) has been moved down to get more
room above it both for it's own sake, and to provide a place for an
extension of POS(0) with now works in 80 columns as well. The vector for POS(0) now points there, tests for 80 columns, and returns the value from
the screen hole if it is, or jumps to the old POS(0) if it's in 40 column mode.
UNTIL (formerly STORE) now points to Hfind, which was augered out to make space for the UNTIL code. Applesoft never called Hfind, and I don't know anyone else who did.
I also fixed a few other known bugs called out in the Applesoft listings.
And since this all fit within the existing Applesoft code, I was able to overlay it on the DEBUG ROM, so I have 65C02 support as well. I had an earlier version of this that used the standard IIe ROM, and SWAP and
TIMER were down in the $C5OO "rabbit hole" along wih Hfind, in case
anyone ever wanted it. This was the version where I discovered that
Program Writer has firm ideas about where commands are located within Applesoft. GPLE did not seem to be so affected. But I really wanted the
65C02 disassembler, and I couldn't figure out how to add it in. My
attempt to remove the slot 3 ROM test and use that space was a dismal failure.
I have a ROM 0 GS, and I am going to try to put the modified Applesoft on that as well along with the ROM 1 upgrade. First I have to build the 32
to 28 pin adapter. If I want double Lo-Res I can use the ampersand
routines from Beagle Graphics.
It's been fun.
Sounds interesting. Will you be making your work available to others to
try?
TheRomExchange.com will soon be releasing a //e and //c version which
would facilitate easy access to your ROM image if it were to be made available.
Regards
Andrew
I'm not opposed to it. The program and test routines are on a DOS 3.3 disk (or disk image). The program that makes the changes is a modified Beagle Basic modifier, and a couple of other unmodified Beagle Basic programs are on the disk along with theCX00 ROM space reader and a merge and split program to combine the CX00 and Applesoft images into one ROM, then optionally split it in two for a beige IIe.
One caveat is that there is a bit of 65C02 code in there, so don't try it on a unenhanced IIe.again. I'm not sure if it's an HTAB bug or could I be reading the aux 1403?
I found one curious bug with the 80 column POS() command: It only works after you print. If I HTAB in 80 column mode, immediately after 1403 is updated to the HTAB position, but POS() returns zero. Print anything, and POS() and PEEK(1403) will agree
The code for the 80 column POS() is;
2C 1F C0 BIT $C01F
10 06 BPL :Old call
AC 7B 05 LDY $057B
4C 01 E3 JMP SNGFLT
4C FF E2 JMP POS(40) ie, the old position call.
I basically copied a similiar call from a C-Space 80 column routine.
Sounds interesting. Will you be making your work available to others to try?
TheRomExchange.com will soon be releasing a //e and //c version which would facilitate easy access to your ROM image if it were to be made available.
Regards
Andrew
Is the bit check going to the old call in this case? I forget specifics, but I do recall that HTAB is 'problematic' in 80 column mode until a print happens.
Hi Mike,
Nope, no emulator requires the ROM image to be inverted.
Antoine
Antoine Vignau wrote:
Hi Mike,
Nope, no emulator requires the ROM image to be inverted.
Antoine
I just checked with KEGS. I think Mike is right. The ROM on the
documentation project has indeed the banks swapped compared to the ones that >KEGS recommends to use. The README.ROM.files.txt in KEGS explicitly excludes >the ROM from the documentation project:
"APPLE Computer and Peripheral Card Roms Collection.zip: Don't use, the
file Apple IIgs ROM1 - 342-0077-B - 27C1001.bin is not in the
format KEGS expects."
I also tried to upgrade my ROM0 using the APPLE2GS.ROM image that KEGS uses >and had the same experience. It did not work so I ended up buying one >instead.
It would be interesting to know why there are these two formats out there.
In article <cybernesto-1639236775@macgui.com>,
cybernesto <cybernesto@macgui.com> wrote:
Antoine Vignau wrote:
Hi Mike,
Nope, no emulator requires the ROM image to be inverted.
Antoine
I just checked with KEGS. I think Mike is right. The ROM on the >>documentation project has indeed the banks swapped compared to the ones that >>KEGS recommends to use. The README.ROM.files.txt in KEGS explicitly excludes >>the ROM from the documentation project:
"APPLE Computer and Peripheral Card Roms Collection.zip: Don't use, the
file Apple IIgs ROM1 - 342-0077-B - 27C1001.bin is not in the
format KEGS expects."
I also tried to upgrade my ROM0 using the APPLE2GS.ROM image that KEGS uses >>and had the same experience. It did not work so I ended up buying one >>instead.
It would be interesting to know why there are these two formats out there.
KEGS expects the ROM file it uses to be in memory order, so for ROM.01,
it wants the byte for $fe/0000 first, and ending with $ff/ffff. Why does it expect that? Since that's the easiest way to dump out the ROM from a real IIgs to transfer the data to your current PC.
In the years since KEGS was created, MAME has added IIgs support. MAME has
a different emulation strategy--they like to dump out the ROMs directly using a direct device reader, and then use that data. The problem with this strategy is very few people in the world have the ability to dump out their own ROMs in this way--so folks using MAME sort of have to get the ROMs from
a ROM repository. You can identify ROMs for MAME since they're the only
ones giving part numbers for the ROMs (the 342-0077-B stuff).
Combine this with another issue: MAME has a lot of smart people figuring stuff out, but they don't seem to like to document what they discover or notify others of issues. So this is the first time I've heard that the ROMs themselves may be in a different order than what KEGS has been using for
25 years. Now that I know this issue exists, I can look into making KEGS accept ROMs in either order.
And even then, this is mostly speculation--I'm assuming MAME didn't store their ROMs in a weird format for no reason, etc. Your data, that burning
the MAME format ROMS works on a real IIgs, is the piece of data I didn't
have previously.
I think the OP's flipped-bank ROM file was probably just messed up. Or perhaps it is for an emulator other than either of KeGS or MAME.
| Sysop: | Keyop |
|---|---|
| Location: | Huddersfield, West Yorkshire, UK |
| Users: | 300 |
| Nodes: | 16 (2 / 14) |
| Uptime: | 67:36:54 |
| Calls: | 6,712 |
| Files: | 12,244 |
| Messages: | 5,356,420 |