info
Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss
Applesoft upgrade finally done
195 views
Skip to first unread message
Mike Spangler
Mar 8, 2021, 1:43:31 PM3/8/21
to
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.
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.
Andrew Roughan
Mar 9, 2021, 7:17:25 AM3/9/21
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
Mike Spangler
Mar 9, 2021, 2:00:16 PM3/9/21
to
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 the CX00 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.
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 again. I'm not sure if it's an HTAB bug or could I be reading the aux 1403?
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.
One caveat is that there is a bit of 65C02 code in there, so don't try it on a unenhanced IIe.
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 again. I'm not sure if it's an HTAB bug or could I be reading the aux 1403?
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.
Lane Roathe
Mar 10, 2021, 12:27:46 PM3/10/21
to
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.
-Lane
-Lane
Mike Spangler
Mar 10, 2021, 12:49:32 PM3/10/21
to
If Basic the intent is to check for 80 column mode, If not in 80 column, use existing 40 column routine. If in 80 column mode, load 1403 and proceed to the rest of the POS routine at $E301. In 40 column mode, POS reads $24, (at $E2FF) and proceeds immediately to $E301.
And your recollection matches what I'm seeing. In practical terms, if you have just issued an HTAB, you know where you are, so POS() isn't needed. If you have printed something of unknown length without a CR, then POS() will work, since you have just printed.
And your recollection matches what I'm seeing. In practical terms, if you have just issued an HTAB, you know where you are, so POS() isn't needed. If you have printed something of unknown length without a CR, then POS() will work, since you have just printed.
I am Rob
Mar 10, 2021, 11:20:04 PM3/10/21
to
I did some Applesoft disassembling as well. DRAW and XDRAW are exactly the same code with just one small parameter extra passed to XDRAW. At the cost of 7 bytes I was able to combine the two, remove XDRAW and save about 100 bytes.
Rob
Rob
Mike Spangler
Dec 9, 2021, 10:56:11 AM12/9/21
to
Since winter has finally arrived again I got back to my project. Thanks to Adrian's Digital Basement on YouTube who ran into the same issue with a ROM 0 to ROM 1 upgrade, I discovered the ROM image I had used was wrong. Specifically, it was inverted. Bank 1 and bank 0 were reversed. Of course it didn't work. I used the correct image with my changes incorporated, and the GS now works.
I think the wrong ROM came from an emulator web page. Do some emulators require the ROM image to be inverted?
The correct ROM was here;
https://mirrors.apple2.org.za/Apple%20II%20Documentation%20Project/Computers/Apple%20II/Apple%20IIGS/ROM%20Images/
I think the wrong ROM came from an emulator web page. Do some emulators require the ROM image to be inverted?
The correct ROM was here;
https://mirrors.apple2.org.za/Apple%20II%20Documentation%20Project/Computers/Apple%20II/Apple%20IIGS/ROM%20Images/
Antoine Vignau
Dec 10, 2021, 1:16:06 PM12/10/21
to
Hi Mike,
Nope, no emulator requires the ROM image to be inverted.
Antoine
Nope, no emulator requires the ROM image to be inverted.
Antoine
cybernesto
Dec 11, 2021, 10:32:58 AM12/11/21
to
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.
Kent Dickey
Dec 13, 2021, 1:34:46 PM12/13/21
to
In article <cybernesto...@macgui.com>,
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.
Kent
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.
Kent
awanderin
Dec 14, 2021, 1:04:12 AM12/14/21
to
My MAME Apple IIgs ROM 01 ZIP file's ROM:
unzip -p ~/.mame/roms/apple2gsr1.zip 342-0077-b |sha1sum
e4fc7560b69d062cb2da5b1ffbe11cd1ca03cc37 -
I have a pretty up-to-date build of MAME, fwiw.
My KeGS ROM 01 file (filename "ROM"):
sha1sum ~apple2/emulators/kegs/ROM
e4fc7560b69d062cb2da5b1ffbe11cd1ca03cc37 /extra/apple2/emulators/kegs/ROM
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.
--
--
Jerry awanderin at gmail dot com
cybernesto
Dec 14, 2021, 11:25:03 AM12/14/21
to
>
> 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.
>
The following ROM images have the same sha1sum and work on KEGS:
> 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.
>
https://mirrors.apple2.org.za/ftp.apple.asimov.net/emulators/rom_images/gsrom01.zip
e4fc7560b69d062cb2da5b1ffbe11cd1ca03cc37 *xgs.rom
https://mirrors.apple2.org.za/ftp.apple.asimov.net/emulators/rom_images/iigs_rom01.zip
e4fc7560b69d062cb2da5b1ffbe11cd1ca03cc37 *iigs_rom01_APPLE2GS.ROM
https://mirrors.apple2.org.za/ftp.apple.asimov.net/emulators/rom_images/rom01.zip
e4fc7560b69d062cb2da5b1ffbe11cd1ca03cc37 *rom01_APPLE2GS.ROM
These ROM images on the other hand do not work with KEGS:
https://mirrors.apple2.org.za/ftp.apple.asimov.net/emulators/rom_images/APPLE%20Computer%20and%20Peripheral%20Card%20Roms%20Collection.zip
90ae5cbd5dff056bf39e44bde76f150e18956d33 *Apple IIgs ROM1 - 342-0077-B -
27C1001.bin
https://mirrors.apple2.org.za/Apple%20II%20Documentation%20Project/Computers/Apple%20II/Apple%20IIGS/ROM%20Images/Apple%20IIGS%20ROM%2001%20-%20342-0077-B.bin
90ae5cbd5dff056bf39e44bde76f150e18956d33 *Apple IIGS ROM 01 - 342-0077-B.bin
But if you try to build the adapter below, the KEGS compatible versions do
not work. Only the last two work.
https://www.applefritter.com/appleii-box/GS03_IIGSLRomReplacement.htm
0 new messages