Jump to content
IGNORED

What would it take?


ledzep

Recommended Posts

Not sure if this has been brought up yet. I've seen before topics revolving around converting A8 computer games to the Atari 5200. But I'm wondering how hard it would be to convert the old Atari Program Exchange cassette game Scram to cartridge format. And, after that, to the 5200. But the main idea would be to get a cart made out of it.

Link to comment
Share on other sites

The problem there is it's a BASIC game. So you're talking the size of the game itself, 8K Basic ROM, 2K FP ROM and also some OS stuff S,K,E handler code - probably another 2K.

 

That should fit in a 32K cart image, but then we need to relocate the FP ROM (easily enough done) and the OS stuff (somewhat more work). And rework the Basic ROM so any system calls are adjusted, and RAM-based variables would have to be changed for all of the above.

 

But the benefit of such a project would be that it'd open up a new world of Basic games that could then be ported easily to the 5200.

Edited by Rybags
Link to comment
Share on other sites

or just port batari basic to the 5200 (or A8 basic) and adapt/convert the program accordingly

 

That would be vastly more work than porting Atari Basic to the 5200 and the adjustments necessary to let A8 Basic progs run from a cart. Batari Basic provides a choice of kernels around the TIA and an API to write games in terms of those kernels. ANTIC and Display Lists perform those functions on the A8 and largely preclude 2600 style kernels. Also, the syntax of Batari Basic will only trivially resemble the syntax of Atari Basic. So a Batari Basic port isn't even remotely appropriate for making carts of A8 Basic games or porting A8 Basic games to the 5200.

 

What would be interesting is adapting the Batari kernels to Antic+GTIA and allowing easy porting of games that don't use additional assembly language between the A8 and the 2600. It's still an insane amount of work but neat to think about.

Edited by frogstar_robot
Link to comment
Share on other sites

or just port batari basic to the 5200 (or A8 basic) and adapt/convert the program accordingly

This statement display such a fundamental miscomprehsion of what bAtari BASIC is that I feel myself developing a migraine. Bonus misery points for use of the ever-abused "just". "Oh yeah, that's simple! JUST completely rewrite it! It's easy to say, so it's easy to do, right?"

 

Arrrgh. Stupidity should be painful.

  • Like 2
Link to comment
Share on other sites

Or use a basic compiler and alter the ASM output accordingly for fitting to a cart.

I tried ABC and MMG compilers. Both fail because of variable GOTOs and GOSUBs and use of ^ power. Anyway I couldn't

compile it, or make changes to make it work.

If it could be compiled, then it could be burned to a AtariMaxFlash cart.

Link to comment
Share on other sites

Compiling still doesn't address the issue of OS calls.

 

It'd probably be not a great deal more work to just do the mini-OS + FP + BASIC like I described, then you'd have something that would allow most 16K Basic programs to work - of course they'd often need modification as well.

 

Source code, or at least commented disassemblies exist for all - so some of the work is already done.

 

Relocating 6502 code, even when the source doesn't exist, is a much easier job these days thanks to PC-based dev-tools.

Link to comment
Share on other sites

Compiling still doesn't address the issue of OS calls.

 

It'd probably be not a great deal more work to just do the mini-OS + FP + BASIC like I described, then you'd have something that would allow most 16K Basic programs to work - of course they'd often need modification as well.

 

Source code, or at least commented disassemblies exist for all - so some of the work is already done.

 

Relocating 6502 code, even when the source doesn't exist, is a much easier job these days thanks to PC-based dev-tools.

 

I was able to compile SCRAM (found in Holmes collection) using Turbo BASIC XL 1.5. There were no errors but the program crashes on a GOSUB with a calculated address. "ERROR - 3 in Line 8240 ($6386) " is the message.

 

Not having had much opportunity to use Turbo BASIC XL I didn't know if the compiler could handle such statements.

 

After some quick testing I found that GOTOs with formulas work fine but GOSUBs crash during execution.

 

BTW, the version of SCRAM I tried seems to work fine in Atari BASIC or in the Turbo BASIC (interpretter) while using an 800XL.

Link to comment
Share on other sites

GOSUB makes a runtime stack entry, so maybe that's why it fails if there's a calculation.

 

Maybe it could be altered to GOSUB to a fixed location, and that line has the calculated GOTO on it.

 

But the thing is - how big does the compiled version turn out?

 

The other thing is - doing an OS/FP/Basic ROM conversion, we'd be dealing with known software that we have plenty of doco for. Translating a compiled Basic program even of half the size might end up being a lot more work.

Link to comment
Share on other sites

Or use a basic compiler and alter the ASM output accordingly for fitting to a cart.

I tried ABC and MMG compilers. Both fail because of variable GOTOs and GOSUBs and use of ^ power. Anyway I couldn't

compile it, or make changes to make it work.

If it could be compiled, then it could be burned to a AtariMaxFlash cart.

 

It also has some ridiculously large numbers, like 24000000. ABC doesn't do Floating Point.

Link to comment
Share on other sites

So you need both of those? If so, then next to zero chance of getting it to work in a 32K image.

 

IMO a "Translator" system of sorts using parts of the 800 OS-B, FP and Basic C would be a good basis to get lots of Basic programs ported over. The extra graphics modes from the XL OS would be just a case of adding some table entries.

 

Just run the thing and ditch most of the functionality of the 5200 BIOS which could then allow commonality in a lot more of the RAM-based variables.

 

It might even be possible to run some Basic programs that need more than 16K RAM... would need some testing, but you could probably jury-rig a Basic program such that the code itself was in ROM, and the variable/array pointers were directed to RAM.

Additionally, stuff like Assembler routines contained in strings or numeric data could just be removed and replaced with USR calls to ROM.

Link to comment
Share on other sites

So you need both of those? If so, then next to zero chance of getting it to work in a 32K image.

 

IMO a "Translator" system of sorts using parts of the 800 OS-B, FP and Basic C would be a good basis to get lots of Basic programs ported over. The extra graphics modes from the XL OS would be just a case of adding some table entries.

 

Just run the thing and ditch most of the functionality of the 5200 BIOS which could then allow commonality in a lot more of the RAM-based variables.

 

It might even be possible to run some Basic programs that need more than 16K RAM... would need some testing, but you could probably jury-rig a Basic program such that the code itself was in ROM, and the variable/array pointers were directed to RAM.

Additionally, stuff like Assembler routines contained in strings or numeric data could just be removed and replaced with USR calls to ROM.

 

Before anyone gets too involved in this project I have one question.

 

Aren't Atarimax flashcarts capable of simulating/emulating bootable disks, enabling BASIC and OSB Translator all at the same time?

 

I thought I read that in very old documentation. I only had an 800. I passed because it didn't sound like the disk emulation feature (diskpacker?) would work on the 800.

 

I'm asking the question, not stating these as facts. It's just what I think I remember. I can't find that old documentation now.

 

-Steve Sheppard

Edited by a8isa1
Link to comment
Share on other sites

That's the computer flashcart though... you can bank-select or switch them off via $D5xx writes.

 

You can do binloads so in theory you could have a program almost 1 Meg in size.

 

But, the 5200 might be somewhat different. On that system you have the existing Flashcart and the upcoming SD cart.

 

I assume you could probably bank-switch on the fly with the Flashcart, which could allow storing extra data in other banks.

 

The SD cart, I assume, loads a cart image from SD into it's own RAM then executes it. No idea though if there's any facility for such programs to perform subsequent loading of data.

 

 

Either way, a big limiting factor is that there's only 16K RAM in the base system. For existing Basic programs from the A8 computers, they have to be stored contiguously.

So even if you could bank-switch on the fly, you'd still be somewhat limited in what you could do via Basic.

 

Although bank-switching on the fly might allow a program that uses more memory - a lot of the OS stuff could be kept in another bank and switched in only when needed.

 

Or maybe some trickery could be employed to copy the bottom half of a Basic program to RAM and the top half could be contiguous, carried on within the ROM. But I'm not quite sure if the OS and Basic would be happy to have the screen living at a lower location than the program start.

Link to comment
Share on other sites

Neat idea to put SCRAM into a cart!

 

Given the current events, I dug out my old SCRAM manual and read it through. Very nice explanations! Find it here:

http://www.atarimania.com/game-atari-400-800-xl-xe-scram_4543.html

 

Then I found an ATR here:

http://www.holyoak.com/atari/files/8BIT/ATR/scram.atr

 

To see what might have happened in Fukushima, I lowered the control rods (SCRAMed) and then immediately turned off all pumps (simulating power failure). The core temperature gradually climbed to nearly 4000 F, even though the fission had stopped. That was close to meltdown, and maybe close to what is really happening in Japan.

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...