Strange GSoft Basic behavior on IIGS ROM01 vs. KEGS v0.91 ROM01

6 posts / 0 new
Last post
bushnrvn's picture
Offline
Last seen: 7 months 6 days ago
Joined: Jan 15 2012 - 10:08
Posts: 193
Strange GSoft Basic behavior on IIGS ROM01 vs. KEGS v0.91 ROM01

So I am working my way through LTP GSoft Basic, and I thought I'd modify a program to see if it worked a different way (see attached bncbll.txt) What I've found is this:

On an Apple IIGS ROM 01 using GSoft Basic 1.2.0 in System 6.0.1 the program returns the following:
* NOTE * Turn down volume. I only had my phone with me to record this so the fan in the background sounds awful. Sorry*

http://youtube.com/watch?v=D00bUraKAXw

I should also note that this is the first time I have ever used GSoft on actual hardware, I just installed one of the new CFFA 3000 cards. I haven't updated the firmware yet and I am using USB. I also have an Applied Engineering GS-RAM (1.5MB) card installed, fully populated. Finder shows I have ~740k free before running GSoft Basic.

Running this program in KEGS v0.91 ROM 01 2.8Mhz, 1MB Ram expansion, the program runs flawlessly.

So idk, maybe my hardware is to blame?

bushnrvn's picture
Offline
Last seen: 7 months 6 days ago
Joined: Jan 15 2012 - 10:08
Posts: 193
Re: Strange GSoft Basic behavior on IIGS ROM01 vs. KEGS ...

Oops - forgot to add the code. Also - just realized I can't attach it. So here it is posted at https://docs.google.com/document/d/1hlubx1_l13vZeIMt_16XfmWK1x1b1R3bgnHaIvcD-X0/edit

speedyG's picture
Offline
Last seen: 4 years 10 months ago
Joined: Nov 16 2011 - 07:45
Posts: 2493
Re: Strange GSoft Basic behavior on IIGS ROM01 vs. KEGS ...

Hello bushnvrn,
one of the reason that strange behavior can be viewed at the IIGS, is the fact that the code within the ROMS is not completely consistent keeping the so called "entry-points" in the ROM...... when expanding the content of the ROM´s the starting adresses of several routine slightly moved from one adress to another adress few bits above.....
this shifting causes strange effects with several firmware-versions of several cards and with several compilers and interpreters.....
for example one of the most common issues is the slight move of the routines that handle the interruptlines of the slot and the so called DMA-handlers....
this causes for example that in some GS several soundcards operate correct and some don´t.
The root of this effect is the kind of way how the software interacts.... so you should examine prior of programming these differences and setup something like a table of parameters, that indicate the shift of these entry-points and a routine to detect the ROM-version....
just a shematic example:
ROM$=peek(ROMVERSION)
rem table of used ROMroutines
if ROM$ = 0 then In_te_rrupt= $cXX10 ....REM don´t spell normal - remember INT and ERR to be reserved words
if ROM$ = 0 then DMA=$cXX20
if ROM$ = 1 then In_te_rrupt= $cXX11 ....REM don´t spell normal - remember INT and ERR to be reserved words
if ROM$ = 1 then DMA=$cXX21
if ROM$ = 3 then In_te_rrupt= $cXX30 ....REM don´t spell normal - remember INT and ERR to be reserved words
if ROM$ = 3 then DMA=$cXX31
......

programsection....
500 if action = yy then peek(In_te_rupt)

.........

if the program is determined only to run at IIGS you just have to detect the ROM-version...
if the program is determined to run at any apple II series computer
you have to expand the routine by detecting the type of computer too...

loop1
detect machine-id
if machine-id = IIGS then loop detect ROMversion

set machine-id-parameters
set ROM-id-parameters..

............

start program

there have been a quite large bunch of entrypoints that moved - caused by the different ROMversions....
..............................
if you don´t detect the ROM-version and use a "fixed" adress as "entry-point" - the jump into a routine at the ROM 1 version might be correct, at the ROM 0 the Jump will enter a few bits too high and miss the first few bytes of the routine of the ROM and crash - or at the ROM 3 the jump will bring you to the last bytes of the routine prior of your target and the return in the ROM-routine will cause a JUMP-back before you even entered the "target-routine" that you wanted to enter....always bear in mind while programming that there is a big difference between:

fixed jump to fixed adress
or
relative jump ( driven by parameter ) to relative target adress ......

it was a common mistake to forget about that .... and a lot of programmers trapped into that pithole ......
the same problems often occured as result of the limited space in the eproms when coding the firmware of a card
( believing that detecting the ROMversion can be avoided with some kind of trick )
or
when coding a program that should translate a code from symbolic-language to machine-code-language like a interpreter or a compiler.....
the nice thing is that this mostly only affects to the IIGS ...

at the IIe only very few "entry-points" moved between the normal IIe and the IIe-enhanced because that firmware did not expand that much as it did at the IIGS.... ( there most moved entry-points were related to the hires-handling )

at the IIGS the amount of firmware nearly doubled the requested space and just even caused to a change of using larger ROM´s

so just to complete the above explained bear also in mind that there are 3 levels within software execution:

program
--------------------------
operationsystem ( calling machine routines of the hardware .... )
--------------------------
computerhardware driven by machine-code of the ROM´s

if the operation-system has mistakes at the section to handle the calls to the ROM´s ( because of mistakes in the parammeters or the ROM-detection )
then of course the same mistakes happen as if you miss to detect the ROM-version at the "program-level"
in that case you must avoid to use the calls from the operationsystem and instead expand your program-level with own routines to handle the jumps into ROM-routines by yourself with correct entry-points ......

this might cause the need to detect the kind of operation-system used too.....

a very ggod example for this kind of trap was the erphi-controller for large disks at the shugart-bus-system:
most controllers for large disks operated with Eproms that contained fixed routines to patch disks at fixed locations with fixed parameters of a fixed combination of drives.... - if you changed the order of the drives, the patched disks did not work any more - because the wrong parameters were loaded for the wrong drives....
- the erphi-controller tried to overcome this problem by avoiding to patch the floppydisks but instead using a routine to read switches on the controller that defined the kind of drive connected there at the controller and their position....
thereafter the routine patched the operation-system in the RAM with the required parameters of the drive....
the trouble started after ProDOS version 1.1.1 ........ every operation-system loads the drive-parameters to another point in RAM slightly shifting from version to version ( yes... - thats also a kind of entry-point ! ) .....
so the fast development of ProDOS throughout the increasing amount of versions ( nearly every 6 to 8 months a new version had been released ) and the poor engineers at erphi could not follow up that revisions that fast ( requiring to update the EPROM on the controller that had to detect the operation-system and then using the correct entry-points of the parameters in the RAM for the drive-parameters to be loaded)..... so after release of ProDOS 1.1.1 the EPROM version 9.1 was the last update of the controller and thereafter the controller crashed at booting later version into nirvanna - because the parameters of the switches from the controller that indicated the kind of drive connected - were loaded to the wrong RAM-locations and then the operationssystem crashed to the monitorprompt.... so this controller can be used with UCSD-pascal-system, DOS, CP/M with no problem - but with ProDOS the controller can only be used up to the Version of ProDOS 1.1.1 ......

and finally to remeber too: some things have been created at a time where only ROM0 existed and therefor did not contain any detection routines for different ROM-versions because at that time there was no need for that....

just a remarkable update:

why this explanations?
well there are 2 possible issues:
The first series of IIGS have been distributed with a VIDEO ROM that had known issues. If the source of the IIGS is not surely known, there might be a chance that also in a ROM 1 board that bad VIDEO-ROM to be found if the board has passed a cycle of service, or if somebody tried before to upgrade from ROM0 to ROM 1 but forgot to exchange the Video ROM too..... the entrypoints of the VIDEO ROM had to be corrected and a new video ROM was distributed....

several emulations and HGR routines in various kinds of interpreters/compilers have problems while interaction .... because the emulation was not entirely checked out prior to release...

sincerely
speedyG

bushnrvn's picture
Offline
Last seen: 7 months 6 days ago
Joined: Jan 15 2012 - 10:08
Posts: 193
Re: Strange GSoft Basic behavior on IIGS ROM01 vs. KEGS ...

Thanks, Speedy. You are always very helpful.

Just an update - I believe I've found the cause of the issue. I am using an Applied Engineering GS-RAM card with 1.5 mb installed. According to the Applied Engineering ram test program from the disks that shipped with the card, the last bay of row D is listed as bad. I've tried resetting the chip and swapping it out, looks like the issue lies with card itself.

I was in the market for a new (larger capacity) card anyway so I will just see if a new card resolves the issue.

Many thanks to all those that offered their help and expertise.

speedyG's picture
Offline
Last seen: 4 years 10 months ago
Joined: Nov 16 2011 - 07:45
Posts: 2493
Re: Strange GSoft Basic behavior on IIGS ROM01 vs. KEGS ...

hello bushnrvn,

Uuuuups..... i didn´t even waist a single thought on the RAM itself.... - but of course bad RAM can also allways cause strange effects and it might solve this issue.....

the point that made me not think about this issue, is that the graphics-pages in the computer have fixed adresses and that they are located also at the IIGS in the first 256 kB of RAM ( at least the first 2 Hirespages )... - and that with growing memory only the "higher" hires pages ( no. 3 to 6 ) are made usable.... so usually simple programs never make use of this "higher" hirespages..... the program itself also does not contain any routine to swap to the use of "upper" hirespages... - so the displayed graphic itself at least remains in the lower RAM ....

so the only possible explanation - to me at least - might be that the operationsystem itself tries to relocate and move the program and the contents up as high as possible to provide as much as possible lower memory and that this kind of behavior causes the program and it´s variables to be moved into the faulty RAM....
at least i have no other idea about this....
sincerely
speedyG

bushnrvn's picture
Offline
Last seen: 7 months 6 days ago
Joined: Jan 15 2012 - 10:08
Posts: 193
Re: Strange GSoft Basic behavior on IIGS ROM01 vs. KEGS ...

I know this is over a year old but I was just going through my old posts and figured I'd provide this one some closure. I replaced my AE RAM expansion with a Briel 4meg card. Problem appears to be resolved. Smile

Log in or register to post comments