Jump to content
IGNORED

Replacing Self Test in XEGS ROM


mytek

Recommended Posts

I'm playing around with something where I'd like to replace the semi-useless Self Test with something more interesting. My test bed is based on an XEGS ROM, but I would presume the idea would be virtually the same in a standard XE or XL ROM.

 

So I found this map somewhere in this forum...

Quote

$0000 - $0FFF ($C000 - $CFFF) Interrupt handlers, misc routines

$1000 - $17FF ($5000 - $57FF) Self Test code (enabled by PORTB)

$1800 - $1FFF ($D800 - $DFFF) Floating Point routines

$2000 - $3FFF ($E000 - $FFFF) Operating System

And sure enough if I go to location $1000-$17FF and insert code from the same location sourced from either of the following files, I will see the rainbow splash screen when powering up.

 

Standard 1200XL rainbow splash screen (when no cartridge inserted)

atarixl-rev2-1200xlselftest.rom

 

Large Fuji rainbow effect

atarixl-rev2-fujiselftest.rom

 

Problem is... that is all I see even when I don't press OPTION on boot, with Basic no longer accessible. Is this because of a checksum issue?

 

I'm using HxD - Freeware Hex Editor and Disk Editor to do my ROM editing. Seems to work fine under Wine in my Linux Box.

 

Link to comment
Share on other sites

Lacking a response to the question of whether the problem I'm seeing with the replaced Self Test code is due to a checksum error (see previous post), it also makes me wonder what is the purpose of having a checksum check for the OS in the first place.

 

Apparently there is a way to circumvent it as described long ago by Bob Woolley...

Quote

The checksum routine can be disabled by storing $EA into $C31D-$C31E

I guess I can give that a try to see if my modified OS will work correctly after the disable technique is implemented.

 

  • Like 1
Link to comment
Share on other sites

Checksum for the OS is a valid concept as a Rom can go partially bad - plus 1200XL being the first XL still had it across 2 physical chips.

 

I suspect you'd need to keep the main body of the later OS since 1200XL has no Basic so there should be no Option processing during startup.

 

  • Like 1
Link to comment
Share on other sites

7 hours ago, Rybags said:

Checksum for the OS is a valid concept as a Rom can go partially bad - plus 1200XL being the first XL still had it across 2 physical chips.

 

I suspect you'd need to keep the main body of the later OS since 1200XL has no Basic so there should be no Option processing during startup.

 

That's exactly what I am doing. I used a dead stock XEGS ROM and surgically removed and replaced the Self Test area with the new code. As I mentioned after doing this it boots up into the ATARI animated rainbow text, whether OPTION is held or not.

 

  • Like 1
Link to comment
Share on other sites

1 hour ago, mytek said:

stock XEGS ROM

This rom is reporting itself as a REV2 rom and I thought the xegs rom was rev4 ..

I took your rev2fujiselftest rom and modified it with my preferential OS modification.

Did a os chksum repair and it is working ok in my U1M 800XL machine.   I go to basic and type BYE and the fuji rainbow appears.

But since it is not the xegs rev4 rom my gamerom slots will not run.

So please re do the modifications to a rev4 xegs rom.

 

Link to comment
Share on other sites

28 minutes ago, Roydea6 said:

This rom is reporting itself as a REV2 rom and I thought the xegs rom was rev4 ..

I took your rev2fujiselftest rom and modified it with my preferential OS modification.

Did a os chksum repair and it is working ok in my U1M 800XL machine.   I go to basic and type BYE and the fuji rainbow appears.

But since it is not the xegs rev4 rom my gamerom slots will not run.

So please re do the modifications to a rev4 xegs rom.

 

I never uploaded an XEGS ROM, but was saying I wanted to add the fuji rainbow to an XEGS ROM in place of it's Self Test routine. Perhaps I wasn't clear about this, which certainly wouldn't be the first time ? .

 

Anyway those two ROM files that I uploaded at the beginning of this thread came from some place else in this forum, and I believe they were variations of the 'XL' ROM from something later than the 1200XL (although I could be mistaken about that). Hence the reason you would have no game slot.

 

So it sounds like since you had partial success running that with your mods after a checksum repair, that perhaps that is what I need to do to my XEGS variant as well.

 

1 hour ago, Sugarland said:

Isn't this because the 1200XL requires a cart for basic so that functionality is not there for basic to initialize so it just shows the fuji..?

If I'm starting out with an XEGS ROM, I would presume that the functionality is there. Unless that is somehow intertwined with the code space for the Self Test routines which I have been writing over.

 

Link to comment
Share on other sites

11 minutes ago, mytek said:

If I'm starting out with an XEGS ROM, I would presume that the functionality is there. Unless that is somehow intertwined with the code space for the Self Test routines which I have been writing over.

Isn't the 800XL/XEGS doing a simple self test on every powerup/cold boot?  Maybe the code you are replacing is shared in the self-test menu area. Is there documentation of the power-up sequence that shows all the address jumps?  If HELP is not pressed, it looks like it's jumping to the fuji draw + color cycle loop instead of what the later XL's/XE's do. Speculating here.

Link to comment
Share on other sites

I'm not sure if this is related to your issue or not, but the XEGS OS has additional code to properly deal with the PORTB bits and the external keyboard. Here is an snip-it from my BIOS, which uses the XEGS OS as its base. I've modified it for my use case, as my keyboard is always attached.

 

;** PPMI - Patch for PMI
;*		PPMI enables on-board game based on CONSOL and connection
;*		of external keyboard.
;*
;*	ENTRY	JMP PPMI
;*
;*	EXIT
;*		Jumps to PMI3 or PMI4.
;*
;*	MODS
;*		Original Author Unknown 1987-05-07

PPMI	=	*			;entry

		lda CONSOL		; console switches
		ror a
		and #%00000011		; bit 0 - SELECT, 1 - OPTION
		cmp #1			; is OPTION pressed and SELECT released?
		beq PPMI2		; if OPTION pressed and SELECT released
	; <BSB> Modify since keyboard is already attached
	IF TESTKB
			eor TRIG2	; bit 0 = 1 if (SELECT pressed == keyboard attached)
			beq PPMI1	; if OPTION pressed and (SELECT pressed == keyboard detached)

				cmp #3
				beq PPMI1	; if OPTION released and (SELECT pressed == keyboard attached)
	ELSE
	ENDIF	; TESTKB

					jmp PMI3; enable BASIC

PPMI1		lda PORTB	; port B memory control
		and #%10111111	; enable game
		sta PORTB	; update port B memory control

PPMI2	jmp PMI4		; don't enable BASIC

 

Link to comment
Share on other sites

As I suspected...

 

I modified an XEGS firmware 32K image and just changed some of the emty bytes just before $CC00 so that the checksum would be wrong.

Tell Altirra to use it and start as an XEGS.  Straight to Self Test, and red bar on the first Rom.

 

Change back to zeros, modify the Self Test part - in the early part just changed a STA $D20F to STA $D21F, so functionally it's the same on a non stereo machine.

Once again, straight to Self Test and fail on the first Rom part.

 

So, the solution - either get rid of the checksum routine or fix your checksum constants so it matches (probably better since the occasional game does an OS checksum and won't run if it's a mismatch)

  • Thanks 1
Link to comment
Share on other sites

On 7/13/2020 at 7:33 AM, Rybags said:

So, the solution - either get rid of the checksum routine or fix your checksum constants so it matches (probably better since the occasional game does an OS checksum and won't run if it's a mismatch)

Sure enough if I store $EA into both checksum bytes *$431D-$431E I can get the XEGS ROM with the 1200XL rainbow inserted into the Self Test space (*$1000 - $17FF) to behave properly, thus still giving me Basic and Game access. This was the method Bob Woolley suggested to deactivate the checksum test, and it does work as advertised.

 

*Note: I am referring to addresses in the XEGS ROM, and not where they get mapped into the Atari memory space, which are two different things.

 

Curious as to what games would specifically be looking for the correct checksum being present, and why?

 

Is there a Windows/MSdos program that could look at an Atari OS file and determine what the new checksum would be? Better yet, fix it as well.

 

Link to comment
Share on other sites

20 minutes ago, mytek said:

Curious as to what games would specifically be looking for the correct checksum being present, and why?

I think there are a number of Synapse and EA titles that do that. For instance, some of the 400/800-only versions of games that I have won’t run from a U1MB because they use a 16K-padded out version of OS B to fit the OS slot. 

  • Like 1
Link to comment
Share on other sites

The checksum is fairly simple - I think it's just adding to a 16 bit number with carry at the given address ranges - you could easily enough work it out from the program code.

 

Failing games - probably stuff that was fairly well protected like early EA games, possibly some Synapse ones.  Onmimon was often a trigger for such games to not work also (unsure if it had a proper checksum or was just rejected because it wasn't one of the "known" ones)

Link to comment
Share on other sites

On 7/12/2020 at 4:29 PM, mytek said:

Lacking a response to the question of whether the problem I'm seeing with the replaced Self Test code is due to a checksum error (see previous post), it also makes me wonder what is the purpose of having a checksum check for the OS in the first place.

There is no general problem with replacing the selftest. Os++ keeps the DUP in this area. However, if the checksum is not correct, it is not the Basic that will be disabled. Instead, it jumps directly to the selftest, as reported.  Probably you changed something in the basic area so its checksum or start flag is no longer correct.

Link to comment
Share on other sites

4 hours ago, Rybags said:

The checksum is fairly simple - I think it's just adding to a 16 bit number with carry at the given address ranges - you could easily enough work it out from the program code.

Maybe simple to you, but that went right over the top of my head :) .

 

12 minutes ago, thorfdbg said:

There is no general problem with replacing the selftest. Os++ keeps the DUP in this area. However, if the checksum is not correct, it is not the Basic that will be disabled. Instead, it jumps directly to the selftest, as reported.  Probably you changed something in the basic area so its checksum or start flag is no longer correct.

I tried this with an entirely stock XEGS ROM without changing the checksum bytes, and it would jump to the Self Test area all the time. never touched the Basic part of the ROM. Then by simply storing $EA at the checksum byte area all was ok again. And to further make sure I hadn't inadvertently altered some other section of the ROM, I put the original Self Test routine and the checksum bytes back as they were, and once again everything worked correctly.

 

Don't know what to say other than that.

 

Link to comment
Share on other sites

2 hours ago, HiassofT said:

Have a look at the "patchrom.cpp" (and "patchrom.h") file of my highspeed SIO patch, esp the update_rom_csum function (and the get_csum1/2 and update_checksum_block functions it calls):

https://github.com/HiassofT/highspeed-sio/blob/master/patchrom.cpp#L135

Thanks for posting that link, but unfortunately I'm not a programmer other than PICs, so I'm afraid that doesn't help me to generate a checksum for my unique XEGS version. It would really be best if there were a Windows executable program that I could load my OS ROM into and it would kick out a checksum as I stated before. Because I plan to make a few different variations for the OS ROM, I need something easy peasey for doing this aspect.

 

I understand the uniqueness of what i am asking, so no surprise if nothing is available (YET ;) ).

 

  • Like 1
Link to comment
Share on other sites

Btw, here's a successful test I did the other day of a 64Kbyte (dual 32K banked XEGS) ROM for testing out my 576NUC+ prototype with the 1200XL rainbow replacing the Self Test (it has Hias's Hi-Patch applied and 4 different 8K slots assigned).

 

 

All ROM switching was done via ALT+number keys on a PS/2 keyboard.

 

  • Like 3
Link to comment
Share on other sites

2 hours ago, Roydea6 said:

This Fuji rainbow seems to be not as colorful as it could be.  Are there any other fuji models available.

 

That's strictly a problem with the camera being used. It was plenty colorful in person ;) .

 

Link to comment
Share on other sites

That method of colour bars is done to death and overly simple.

 

The much better one is that which goes 0-F then F-0 for each colour giving a proper stacked cylinder look rather than the cheap venetian effect.

(doing luma in increments of just 1 also very valid since upgrades like VBXE and Sophia support doing 256 colour palettes.

  • Like 1
Link to comment
Share on other sites

11 hours ago, mytek said:

Thanks for posting that link, but unfortunately I'm not a programmer other than PICs, so I'm afraid that doesn't help me to generate a checksum for my unique XEGS version. It would really be best if there were a Windows executable program that I could load my OS ROM into and it would kick out a checksum as I stated before. Because I plan to make a few different variations for the OS ROM, I need something easy peasey for doing this aspect.

 

I understand the uniqueness of what i am asking, so no surprise if nothing is available (YET ;) ).

 

I had a quick go at it and added options to only verify and fix 16k XL/XE OS ROM checksums to my patchrom tool. I've attached a win32 console executable.

 

Run "patchrom -c atari.rom" to verify the ROM checksums or "patchrom -C atari.rom fixed.rom" to save the ROM with fixed checksums to "fixed.rom"

 

so long,

 

Hias

patchrom-133.zip

  • Like 5
  • Thanks 2
Link to comment
Share on other sites

4 hours ago, Rybags said:

The much better one is that which goes 0-F then F-0 for each colour giving a proper stacked cylinder look rather than the cheap venetian effect.

(doing luma in increments of just 1 also very valid since upgrades like VBXE and Sophia support doing 256 colour palettes.

This is for Michael’s new 576NUC+ project. There’s no guarantee that it will be built with a VBXE or Sophia, though I supposed some might. Would that method look okay with a standard ANTIC and GTIA combo?

Link to comment
Share on other sites

IMO either colour bar type looks better if it's incremented by 1 per scanline rather than 2 (the 1200XL one there is by 2).

The Nautilus title screen provides a good example of venetian colour bar incremented by just 1 per scanline.

 

By doing it that way, the result would either be a luma change of 1 each scanline or 2 every second depending if you have either enhancement installed/enabled.

 

 

  • Like 3
Link to comment
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

Loading...
  • Recently Browsing   0 members

    • No registered users viewing this page.
×
×
  • Create New...