Gauntlet ROM code

[Wrathchild]

For any aspiring ROM makers, this may help a bit. Primarily it highlights the differences in the XEGS, MegaCart and Flash Cartridge models but also shows a way of using CC65's powerful assembler and linker to easily construct ROM images. Ask any questions about it can be posted on this topic and I'll try to help as much as possible to describe how/why things were done.

 

Also it gives away a nice little simple Run-Length-Encoder that I knocked up in Java to ensure that blocks don't span cartridge page boundries. The decompression code is in the routine 'load_data_file'.

 

Ultimately the three separate source files are common enough so that one version containing #ifdef statements to control what is included based upon the selected cartridge model could have been developed, if someone would like to do that and show me how the makefile could be used to build all 3 I'd be grateful, mine seems to rebuild the ROMs even when the object file hasn't changed.

 

Regards,

Mark

Gaunt128.zip

[danwinslow]

At first glance, this looks VERY nice. Thanks a lot! I will probably post more questions as they occur after I look at it in depth. I am working on an ethernet binding for the 8 bits, and would like to cart it if possible.

[Wrathchild]

At first glance, this looks VERY nice. Thanks a lot! I will probably post more questions as they occur after I look at it in depth. I am working on an ethernet binding for the 8 bits, and would like to cart it if possible.

835732[/snapback]

Great idea, anything to do with the Contiki/uIP work done so far?

I have a USB cart and would like to turn my hand to a driver for

those cheap USB to Ethernet adaptors, but a few other bits to do first

 

Best Wishes,

Mark

[danwinslow]

I have looked at uIP. Its seems to be workable, but its not ported yet, and its not complete. The real problem is that it is just impractical to get a functional TCP stack and an ethernet driver layer together on an 8 bit machine, *and* have room left over for applications. I don't want to say its impossible, but if it is, its beyond what I can do. I am taking a different tack that will involve an external smart ethernet board. The stack and support hardware will be on the board. Then on the Atari side will be a light weight SIO-style driver underneath a sockets.h type library. The sockets.h layer will just be a passthrough, but it will allow native compilation of standard TCP apps on the atari, with almost no TCP overhead. You will be limited, of course, to the 19.2k SIO transfer rate, but that really can't be helped...*unless* maybe I can interface the smart board and software on a cart..say a flash cart maybe. Or maybe just putting Contiki or whatever on the flash cart would be good. Bank swapping could allow some stretch room..I think.

But anyway, specifically Contiki, along with maybe one of the tiny linuxes (lng maybe ) is my target. I would really like to strip the TCP layers out of Contiki, it would make it a lot more practical in terms of size.

[danwinslow]

Oh, and on the USB subject, I have a cart too, and have done some preliminary experimenting with a ethernet/USB. Using the USB CART project stuff from the ABBUC guys I was able to see the ethernet USB...the atari driver didn't know what it was of course, but it did manage to dump out some of the ident strings and stuff from the descriptors. It didn't look right, some of the strings I think are longer than what they had planned for, but as far as it went it seemed to be able to find it.

[Wrathchild]

Similar here, the first UsbTest disk didn't detect these devices, but the latest one does. I also have a little IrDA device but as the function of that is limited against an Ethernet device, I'll not concentrate on that.

 

What's nice about these devices is that, I think, you can use a small transfer buffer between the device and your driver software, e.g 8 bytes. Saying that though, making the driver work through the OS's I/O routines/handlers would be desirable.

 

General Question: Has any work been done to make CC65 libraries (in 'C',ASM or a mix) for use with the USB cart?

 

Regards,

Mark

[danwinslow]

Well, I have converting the forth and assem from the cart project to CC65 on the stack, but I doubt I'll get to it any time soon.

[Shawn Jefferson]

The real problem is that it is just impractical to get a functional TCP stack and an ethernet driver layer together on an 8 bit machine, *and* have room left over for applications.

 

I took a quick look at it (Contiki) once. I think it may be possible to use extended memory to swap the applications in and out (or a bank switched cartridge). The only parts that need to be resident in low ram are the scheduler (the event kernal I think it's called?), the tcpip stack and the screen drawing routines. The applications themselves could be swapped out by the event kernal, since it calls all the applications. I guess some sort of wrapper that banks in the right memory block would be needed for each application.

[danwinslow]

Yeah, thats true. I have been thinking about that too...without a page fault type of mechanism you would either need to (a) manually trap all instructions to go through page checking/swapping routines for control transfers and memory fetches, or (b) restrict yourself to memory accesses through an allocator that maintained usage and location tables, or © design things so that they are naturally packaged in 16k chunks, ie., no user program could be over 16k in length.

(a) would be really really slow I would think. (b) would be good...but it would some overhead itself to maintain page tables and would really only work for data. © seems possible but restrictive.

Mostly I have been thinking about (b). There would need to be unswapped data in low memory that would be a page table that indexed some virtual space of chunks of data.

You would have to set up all memory allocations and subsequent access through user code. You would also need some kind of RAM window to map your data in and out. You couldn't just hit any piece of data with a direct load...probably best would be to set up a lower memory access window, say 1 page. When the memory access routine went to fetch a particular address, it would figure out which 16k mem bank has the data, swap it in, move the appropriate page to the RAM window, and swap back in the 16k block ( which might after all have contained code that is currently expecting to run ). So, really you'd have to use a completely new addressing scheme...something like a 24 bit scheme in which bits 0..7 specify an offset from the RAM window start, and bits 8..15 specify any one of 256 1 page chunks, and the other bits select a 16k block....or something like that, you get the idea. Another issue is that the biggest memory object you could work with at once would be 256 bytes...maybe if you took like the last 2 bytes and made it a 'chain field' to the next block you could stitch things together.

 

At any rate, you'd have to go to a completely new way of addressing memory. You would need to build direct support for it into the compiling tool. It definitely wouldn't be compatible with any existing source code. It might be interesting tho for something like Contiki.

Edited April 13, 2005 by danwinslow

[danwinslow]

Hmm, upon further thought I guess the way to do this would be with a (soft) segmented architecture like x86 /shudder. You could have a couple page 0 locations that were 'segment selectors', and would control which 16k block of extended memory was swapped into the RAM window. They would also form the base for 0-16k offsets into the currently selected segment. So swapping segments would be a matter of loading the segment selector with the correct value and swapping in the correct block. An actual address would be an 16k offset from the segment base..uh you'd need like 14 bits for that offset. So if the segment 'registers' were 8 bits, that would give you 256 16k segments. Added to the 14 bits for offset, that gives you 22 bits...which is cool as you have 2 bits left over to do something else with...dirty bits or status bits or something, maybe if you paged to disk as well. You'd need to add direct support for this in your compilation tool..all data accesses would have to be relative to the beginning of your RAM window. You take a 24 bit address, split off the segment selector 8 bits, check if that block is current and swap it in if not, and then use the bottom 14 bits as an offset. Does this make sense or am I babbling?

Edited April 13, 2005 by danwinslow

[Shawn Jefferson]

At any rate, you'd have to go to a completely new way of addressing memory. You would need to build direct support for it into the compiling tool. It definitely wouldn't be compatible with any existing source code. It might be interesting tho for something like Contiki.

836410[/snapback]

 

I think you are making it more complicated than it needs to be. The way the Contiki system works (last time I looked) is that there is a main "kernal" (is that the right word to describe it?) the Event dispatcher. This is the main part of contiki and calls all the other parts (even uIP.)

 

In a system with extended RAM (like the 130XE):

 

So, you would need to have uIP, the dispatcher and the graphics/screen drawing functions in unbanked RAM (2000-3FFF, 8000-BC1F). The applications themselves (the web server, http client, email client, etc...) could all be in the banked ram at $4000-7FFF. This would include the CODE, DATA, RODATA and BSS segments for that application.

 

The event dispatcher calls a routine from the application. You would need to "trap" that call with a small wrapper of some sort that banks in the correct extended bank and then proceeds with the call.

 

The only real problem I can see is that you would have to patch the Contiki code, so you couldn't use it "out of the box" and each application would couldn't exceed 16k. Also the uIP stack, event dispatcher and screen drawing routines couldn't exceed the available ram outside the bank window (well not easily... you could bank some of that stuff in and out too I imagine.) That's as far as I got in thinking about how to do it on the Atari... and I don't know if it would be possible because of these limitations. It's all pie in the sky anyway until an ethernet cartridge is available.

[danwinslow]

Yeah, I was looking at a more general case than just switching out entire applications in a 16k bank.

If I am successful, we will have an easily installed ethernet device in a few months, for around 100$ of hardware, with an optional 32MB flash 'hard drive' for $50 or so more.

[carmel_andrews]

Hello Mark, long time no hear or see... nice to see your back with the A8, what ever happened to your elite game... or am i confusing you with something else

[Wrathchild]

nice to see your back with the A8, what ever happened to your elite game...

I never went away Search around these boards for info on Elite's lack of progress... certainly won't be resurrected in the near future

PM me for any further followup. Best wishes, Mark