RAM issue 800XL vs 130XE urgent for abbuc!

[+therealbountybob]

Hi guys,

my boot ATR/Disk game loads ok on a couple of emulators with any of the firmware/ram options selected.

 

1.

On my 130XE I had garbage instead of initial title screen. I had included JAC!'s code [LDA #255 STA PORTB LDA #1 STA $03F8 STA COLDST] to automatically disable basic and make reset reboot so I tried without Option held and it ran ok?

 

2.

On the 800XL the title screen seems to appear but possibly has the chset corrupted.

Am I missing something re the RAM on the 800XL vs the 130XE?

I'm using

Top half of page 0

0400-06ff

code on pages 8-30

MAPS 30-90

90-BFFF tables fonts etc.

[i'm not intentionally using anything that is 130XE specific?]

 

3.

Should I be able to use page 7 to start my code on?

 

Thanks

 

 

[+CharlieChaplin]

Hmm,

 

just some stupid questions from me...

 

- is it a real bootdisk, without DIR and VTOC ? Or is it a file with some bootloader ?

Remember: The emulators can load lots of *.XEX files that will not work on real A8 (e.g. DOS, Gamedos and Bootloaders require some space ranging from approx. $0700-1Cxx or 1Dxx for DOS 2 and approx. $0700-09FF for gamedos or bootloader)...

 

- the code in page 3 (STA $03F8) is for what ? My programs use $0244 (equal to Poke 580,1) for a coldstart, whereas most programs I have that use code in page 3 will not work on XL/XE computers but require the OLD-OS / translator disk...

 

attached some small tools that might be useful for you:

 

- Bill Wilkinson himself (author of the book "Inside Atari Basic" and one of the programmers of 8k Atari Basic) released a small ML-file in Compute! magazine, named BASOFF.COM, it uses page 4 ($0400-042C, Init $0400) to switch off Atari Basic, right after its job is done, page 4 is free again...

 

- I found lots of programs that do a coldstart after Reset is pressed and simply extracted/copied the $0244 segment from them to use it in my own programs; named this small routine COLDSTA.COM

 

- if you used ABC or MMG compiler, then make sure one cannot hit BREAK to abort your program (an error message will appear, you have to press Start, Select or Option to continue); Poke 566,x in AB will prevent this, so does the ML-routine which I named POKE566.COM...

 

- if you want to switch off the screen while loading use Poke 559,x in AB or the equivalent ML-routine named POKE559.COM

 

- if you want to switch off the SIO-noise use Poke 65,x in AB or the ML-routine named POKE65.COM

 

Since I am not a programmer, I cannot help you any further with your problem. Hopefully someone else can.

Greetings, Andreas Koch.

 

P.S.: Last stupid question, isn`t $BC00-BFFF the screen area and loading data/fonts into it will display garbage while continueing loading ?!?

small_tools.zip

Edited August 29, 2014 by CharlieChaplin

[+JAC!]

ad 1)

 

Boot images that load stuff to $A000-$BFFF will only work if the user holds down OPTION during power up.

Only with .XEX files you can have INIADR segments to relief the user from that.

My offer still holds to turn you ATR into an XEX :-)

It'll really be the best way. Reduced loading times on real HW included.

 

ad 2)

May be a variation of 1).

 

ad 3)

With a boot image you cna load to any address at $480 and above.

[+therealbountybob]

thanks for the replies.

Straight boot disk / no DOS (used the bootmajster utility)

yes garbage on screen during load but not worried about this at the moment?

 

ad 1)

Boot images that load stuff to $A000-$BFFF will only work if the user holds down OPTION during power up.
Only with .XEX files you can have INIADR segments to relief the user from that.
My offer still holds to turn you ATR into an XEX :-)
It'll really be the best way. Reduced loading times on real HW included.

like I said it runs on 130XE ONLY with option NOT held! ???

Any idea why the same program doesn't run on the 800XL [both from 1050 boots] ???

If I get the ATR working then we can look at creating an XEX!

[+CharlieChaplin]

Well,

 

if I remember correctly, the "Bootmajster" is an A8 program which takes a COM/XEX file and turns it into a bootdisk. I would not be too surprised if it adds some bootcode to the diskette and hides the file somewhere/somehow (maybe in a similar way XBoot by FoX does). Next, the Bootmajster supports only medium density, 130k format and requires 128k RAM to convert your file into a bootdisk - maybe it also requires 128k RAM to run this bootdisk ?!? I tested some programs with the Bootmajster in the past and after converting, some programs worked fine, but some did not work anymore or showed garbage...

 

All in all, Bootmajster does not seem a good option to me... so I never use it again.

Take JAC`s offer for help !! (He might convert your Bootmajster ATR into a XEX or compress+relocate your original XEX into a DOS or gamedos loadable file.)

Edited August 29, 2014 by CharlieChaplin

[+JAC!]

Maybe a dumb question, but do they have the same OS? Most upgrade OSes toggle the semantic of the option key.

>If I get the ATR working then we can look at creating an XEX!

In fact getting the XEX working will probably be faster anyway (15 mins).

[+therealbountybob]

Maybe a dumb question, but do they have the same OS? Most upgrade OSes toggle the semantic of the option key.

>If I get the ATR working then we can look at creating an XEX!

In fact getting the XEX working will probably be faster anyway (15 mins).

>>>

Boot images that load stuff to $A000-$BFFF will only work if the user holds down OPTION during power up.

I'm probably going to have to admin defeat and get your help tomorrow if possible. I fairly sure this is not an ATR or Bootmajster issue. I'ts been another very long day - I've not had the game working to actually test fully but I think everything is playable, I would have liked to spend a week laying out the levels better and adjusting controls and parameters but sadly this issue has taken way too much time.

 

It's a but strange and I'm thinking the problem is something technical: perhaps some use of A000-BFFF is the issue?

 

I've tried a cut down XEX from a DOS 2.5 load:

OK On the XL with Option held

OK On the XE with NO OPTION/BASIC ON

Only occasionally runs on the XE with OPTION held! when it fails has garbaged display instead of title screen

 

the XE is standard from new, the XL is 2nd hand so not sure of it's history.

 

this is not scientific testing as I've been trying to finish the game programming at the same time.

 

If you can help please let me know what you need. Remember I'm fully developing the game on real hardware (130XE/MAC65 with a little help from APE). My game scans the playfield maps for 'marker bytes' and builds tables of ram addressed for these for item placement. I'm doing one more full assemble for a boot disk now so I'll test that tomorrow and check here again.

 

Thanks,

Jason

[phaeron]

Check if you are loading on top of an active display list with DLIs enabled. One difference that can appear between an 800XL and a 130XE is that the former has pull-ups on the data bus and the latter doesn't. If ANTIC starts reading garbage for a display list, it can end up in an unassigned memory region where this makes a difference. Fix is to never load on top of the active display list -- shut it off in vertical blank via an init segment first.

[+therealbountybob]

Check if you are loading on top of an active display list with DLIs enabled. One difference that can appear between an 800XL and a 130XE is that the former has pull-ups on the data bus and the latter doesn't. If ANTIC starts reading garbage for a display list, it can end up in an unassigned memory region where this makes a difference. Fix is to never load on top of the active display list -- shut it off in vertical blank via an init segment first.

I guess I am loading over the default display list's ram - I wondered if this was a problem... this might explain why sometimes it runs. The emulator seemed to end up on a random location when it crashed.

If you have time please could you post the code for this "loader program" and how to get it to then load/run my game ? [is there a quick&dirty fix where I could first load some bytes over the default dl to disable it?]

Thanks

 

I've created a smaller DOS/XEX version just incase the ATR is not ready in time - this has the same issue: sometimes works sometimes garbage. If there's a fix for both I would be grateful

Edited August 31, 2014 by therealbountybob

[Rybags]

Having the display/DList go crazy shouldn't be a big problem so long as the DLI isn't enabled - aside from unwanted display of course.

 

Another thing - when loading and changing screen stuff in an Init segment, it's a good idea to put a wait of 1 frame after changing DList and even colours - the continuation of loading will disable Stage 2 VBlank most of the time which means the changes might not go through for a long time.

[+therealbountybob]

Having the display/DList go crazy shouldn't be a big problem so long as the DLI isn't enabled - aside from unwanted display of course.

are you saying that it shouldn't matter loading over the default screen ram (if you accept the garbage until your program runs) as there is no DLI by default ?

 

Another thing - when loading and changing screen stuff in an Init segment, it's a good idea to put a wait of 1 frame after changing DList and even colours - the continuation of loading will disable Stage 2 VBlank most of the time which means the changes might not go through for a long time.

please can you explain what an init segment is (the setup part of my assembled program or another loader program that runs first - that I don't know how to do - see above post) ?

and "wait of 1 frame" would this need to be wsync or a NOP or use a counter ?

 

thanks

[Xuel]

An INIT segment is a just a segment in your object file that loads to memory locations 2E2 and 2E3 and contains an address that the loader will run immediately before proceeding to load the next segment. What Rybags is suggesting is putting some code to modify the display as the first segment. The second segment will be an INIT segment that calls this code. The third and subsequent segments can then load where the display was.

 

For example, here's the code that I use to create an INIT segment that disables BASIC and turns off the display during loading:

 

    org $2000
    ; disable BASIC
    lda #2
    ora PORTB
    sta PORTB
    ; turn off screen
    lda #0
    sta 559
    lda $14
wait_vblank
    cmp $14
    beq wait_vblank
    rts
    ini $2000

I'll try it with MAC/65 and let you know.

Edited August 31, 2014 by Xuel

[Rybags]

What I meant is - so long as DLI isn't enabled on Antic, Display List corruption is little more than a visual annoyance.

But if DLIs are enabled, you potentially might get one every scanline - it could even be sufficient to crash the computer via stack overflow.

[Xuel]

I confirmed the following works under MAC/65:

 

10       .ORG $3800
20       LDA #2
30       ORA $D301
40       STA $D301
50       LDA #0
60       STA 559
70       LDA $14
80 WAIT_VBLANK
90       CMP $14
0100     BEQ WAIT_VBLANK
0110     RTS
0120     .ORG $02E2
0130     .WORD $3800
0150     .ORG $3900
0151 RAINBOW
0152     LDA #6
0160     STA $D40A
0170     INX
0180     STX $D01A
0190     CMP $D40B
0200     BNE RAINBOW
0210     TYA
0220     TAX
0230     DEY
0240     JMP RAINBOW
0250     .ORG $02E0
0260     .WORD RAINBOW

You can change the "LDA #0 / STA 559" to "LDA #$40 / STA $D40E" to just disable DLIs instead of disabling the screen.

 

Here's an ATR you can try. It has the above code and the assembled OBJ file which you can load "L" from DOS:

 

test.zip

[+therealbountybob]

I assembled this and ran the object code ok... but (sorry!) still not sure how I use this, do I just add it to the start of my file replacing RAINBOW with my program as is?

I have this:

(I had the basic off and screen off in the setup section. I guess not having the port b oring explains the XL vs XE issue - I was just storing $ff here...)

 

 

[Xuel]

Yep, just put lines 10-130 before your line 3980, assuming that is indeed the start of your code. Hopefully your lines 0-3970 are just comments and/or equates?

[Xuel]

Actually, it looks like your ZZBFFF label is for checking that you haven't overrun into the OS ROM area, so you should put the disable code between that and 3990. But that seems to imply you have something loading into the $B0 page above? If so, just stick the BASIC/display disable code at the very top of your listing.

 

I don't think storing $FF in PORTB would be too problematic since that will switch off banking in a 130XE, but I think just flipping the BASIC bit alone is safer in case of some kinds of RAM expansions.

[+JAC!]

Hi Jason,

 

just to make sure you see it: I just sent you an XEX version that loads correctly from DOS on my 65XE!

[+therealbountybob]

Thanks everyone really appreciated - at least I have made the deadline with a working game. I'll take a look at more of this goodness tomorrow and see if I can get it to work for the final polished version. I think I've been on the 130XE solid for the last 8 days... can we have the contest every 3 years

[+therealbountybob]

Now that the pressure is off I've been experimenting with creating my own boot disk:

Using the BootMajster utility to create an ATR works fine with e.g. my code at 2000 onward (a small version of the game)

 

Keeping the init segment (above) at 0700:

Rainbow program at 0714-(0727) (the next address after the init segment) works

Ramp Rage at 0714 fails

 

Ramp Rage at 0800 works (but I need the extra space so want to start it at 0714 if I can)

Rainbow program at 0714 works

I added a small table (50 bytes) after the Rainbow program fails

changed the table to 20 bytes works!

So it looks like some of page 7 is required during the loading process?

I thought this was only for DOS/file loads?

Perhaps the Boot Majster utility's created ATRs are using this too?

 

Any thoughts?

[attached some of the examples]

TestLoader0700Rainbow0714-20ByteTableWorks.atr

zTestL0700Rainbow0714Works.atr

zTestLoader0700Rainbow0714-50ByteTableFails.atr

[Xuel]

I just looked at Boot Majster and I see that it loads at 700-77F and uses 780-7FF as the sector buffer, so the lowest you can safely load with it is 800. Your successful tests with the rainbow program just happen to work even though the loader is overwriting parts of itself -- but as you've demonstrated if the amount that you overwrite is too much then it crashes.

 

Possible fixes:

• Move your page 7 data to page 6 and don't load anything into page 7.
• Hack Boot Majster to use page 6 instead of page 7.

[+therealbountybob]

Thanks for the explanation I'm glad to have finally got to the bottom of this as I've spent a lot of time (and a lot of long assembles on the XE) thinking it was something I was doing. I'm already using pages 4-6ff but now I know this I can organise my code to fit. Your loader works nicely btw with my 130XE, basic on or off, so thanks again

 

I am working on a post abbuc version of Ramp Rage as there are a few things that need a tweek and to see if I can improve some of the routines. After the compo I will be opening it up for some improvements and to learn some more Atari goodness. Looking forward to the abbuc disks arriving soon

 

 

p.s. Here is the link to the Boot Majster and other boot utilities ATR:

http://atariage.com/forums/topic/207712-how-to-make-your-own-bootdisk/?p=2679172

Edited September 18, 2014 by therealbountybob

[+CharlieChaplin]

Hmmm,

 

allthough JAC! already gave dozens of helpful tips on programming for the ASC e.g. here:

http://www.wudsn.com/index.php/productions-atari800/tutorials/tips

 

I think that I said somewhere (here at atari-age forum), that you are on the safe side, if your program a) does not use $0700-1FFF when loading from DOS or b) does not use $0700-09FF when loading from Gamedos or Bootloader.

 

Luckily, JAC! patched and packed your program in such a way for you, that it most likely works under DOS, but evil as I am, I put it on a gamedos disk (NanoDOS by the way). So it can take part in the contest. But this trouble could have been avoided. And I am not saying this, because I am angry (not at all), its just a note like "read the tips" and give us less grey hair... ;-)

Edited September 19, 2014 by CharlieChaplin

[+JAC!]

The "problem" is that Jason uses real Atari old-school environment for development. (Of course is the only real way of doing it, don't get me wrong). And due to the way MAC/65 works, there's no way of compiling, packing and saving such a large program in the native environment with existing tools. I ran into the same issues with my (still unfinished) ACTION! program (which is part of the reason why it's not finished). The only way I can think of is to have the level data packed and depack it when need. If you know that and consider that from the start it'll work out. If you realize it the week before the deadline, well, there's help if you need it :-)

[+therealbountybob]

I did read the tips but always planned to make (and enter) a boot disk to fit in more map data. At the end I got bogged down in the basic off stuff etc which caused a lot of confusion/anomalies and cost me a lot of time. Data compression etc is for a future sequel, someone here offered to help with that too. Remember also this is my first real assembler program from scratch

 

I wanted to do this 100% on real hardware, though I did use APE as my 1050s were not all working 100%. I intended the game to work on the 800, XL and XE too.

 

The good news is that I now have a full "boot" version of Ramp Rage working on real hardware so I can now get to play and test the full game properly after making updates. I've used xuel's init segment (above) and the Boot Majster Utility and they both work very nicey. My program is on pages 0080-0100, 0400-0600, 0800-bfff and i'm even re-using page 7 after loading to store a table!

 

The abbuc version on Ramp Rage has a few 'tuning' issues e.g. the baddies speeds are too slow and should also vary with the scrolling; but there is enough working for people to get the idea. I've been making some more tweaks again today and will release a post abbuc version with some improvements

 

Thanks again for everyone's help, hope you enjoy the game