110 replies to this topic

[Delicon]

Got the boards in. I was able to populate them, I dont think I will be able to test tonight and I think I am headed out of town for a couple days, so it may not be until the weekend before I know anything. But the cart fits in a case beautifully.

Here are a few pictures. I populated the USB parts for the programmer, that is why some parts appear to be missing.

Vern

Attached Thumbnails

• 
• 
• 

[vb_master]

That's really nice!

[Delicon]

Well, I have been trying to test today, but I ran into a bug with the Xilinx software. I am using version 6.x, so I decided to upgrade to 7.1. The file is like 350MB, not a big deal if you have broadband or dialup (yes I mean dialup). I have the worst thing you can own DirecWay 2 way satellite. They have this wacky fair use policy. It seems like whenever I download a large file, I only get about 150MB before they limit me to 4KB/sec. Then it stays that way for hours. It means I have to get some spyware infested download manager, just so I can continue the download tomorrow for another 150MB. I wish I could get real broadband!!!!

Oh well, I will be gone for the weekend, so I wont be making any progress till Monday.

Vern

[vb_master]

Get FireFox.

[Delicon]

vb_master said:

Get FireFox.

I do use Firefox. Firefox does not have a download manager that supports download resuming (pausing is not resuming).

Anyway, mini update. I am still fighting the Xilinx software, but I found a work around finally. So not a whole lot of testing. Only minor things, no showstoppers. USB works, CPLD reprogramming works, flash access works, and SRAM access works. I didnt get a chance to actually play a game, but I dont see anything that could be a problem. Still need to play a game and test microcontroller programming via RS-232.

I have to go out of town again, Ohio this time. So a couple more days of delay. Sorry.

Vern

[vdub_bobby]

Any new news on this?

[batari]

vdub_bobby, on Thu Jun 2, 2005 12:04 PM, said:

Any new news on this?

I ordered the parts and built one, but I haven't been able to use it yet. Delicon said he was still working on the files but was busy at the moment. Last I heard from him was about a month ago.

If I don't hear back soon, I'll try to figure out how to get it working myself...

[supercat]

Delicon, on Wed Mar 16, 2005 9:00 PM, said:

In order to program the flash, a microcontroller needs access to the full ACART.

If one starts with a flash that contains a boot loader, does one even need a separate microcontroller? I would think the Atari should be able to program itself (a routine to program a 64-byte block of flash would be copied into RIOT RAM and run from there). One wouldn't have niceties like a hardware UART and would thus likely be limitted to 19200-N-8-2 or maybe 38400-N-8-2, but that shouldn't be a problem.

Right now I'm working on sketching out an as-cheap-as-possible design for a RAM+flash cart intended to be a platform for SALEABLE games by homebrew developers. The goal is to use one RAM, one flash, a 22V10, some resistors, and some caps. In the cheapest configuration I could envision, the cart would support 32K flash and 1.75K of RAM and would have two jumpers. With both jumpers installed, the cart could be programmed by a bootloader; with them removed, the cart would be write-protected. There would be one bank-switching method available which does not AFAIK match any other known method (though if someone could direct me to something close that might be useful).

Adding a few more jumpers would allow the use of larger RAM, though with some loss of ability to control RAM and flash addresses separately. I don't know what different programmers would want to do, so leaving such options open might be desirable.

Flash would be divided into eight 4K blocks. Removing a jumper would force A14 high, mirroring the bottom four into the top four and allowing more easily the use of more RAM with 16K or smaller programs.

In minimal configuration, RAM would be divided into eight 256-byte page, accessed at $1000-$11FF in Superchip fashion. Depending upon the status of a jumper, selecting RAM page 0 would disable the RAM and make the flash available there.

For applications requiring more RAM, jumpers would allow upper-order address banking bits from the flash to be directed to the RAM chip, allowing up to a total of 16K RAM, but with restrictions on access.

If the bootloader jumper was installed, selecting a RAM bank 4-7 would cause all accesses in the $1000-$1FFF range to be interpreted as flash writes. The bootloader would have to copy a small routine into ZP RAM, switch RAM banks (turning on write mode), do any necessary writes, switch RAM banks back, and return to running from flash.

Bank switching would be keyed on reads or writes to selected addresses in the range $0400-$0F7F. Note that Stella and/or RIOT would be mirrored here, but the addresses could be chosen that would have no effect. Note that address bits 2-7 would not be decoded but are assumed below to be '0'.

Address %0 010a **** **bc - Select RAM page abc

Address %0 1abc **** **de -- Sets flash block bits XYZ thus:
X=dX+a; Y=dY+b; Z=eY+c.

Note that it's possible to manipulate either the first two or the last bit of the flash block address without affecting the rest. This should allow for easy sharing of the register between RAM and flash addressing.

Anyone know of any bank-switching methods that are remotely similar (that would already be supported in emulators, CC, KC, etc.)?

[batari]

vdub_bobby, on Thu Jun 2, 2005 12:04 PM, said:

Any new news on this?

I recently heard back from Delicon. Apparently he was busy sipping Pina Coladas in the Carribean these past 2 months

I got the necessary files from him and ... drum roll please ... the cart works! I'm a happy camper with renewed faith in my soldering skills.

Anyway, I'm sure you'll all be hearing more particulars from Delicon, so those of you who want to build one of these yourselves, stay tuned.

[supercat]

I'm working on a minimal RAM+EPROM cart design which I'd open-source if anyone would be interested. Approximate part BOM:

1-32Kx8 EPROM
1-32Kx8 SRAM
1-22V10
7 resistors
5 small caps (3 bypass caps + 2 small timng caps)
3 jumpers (intended to each be soldered one of two ways to select one of two configurations)

The device would accommodate the following bank-switch methods. Note that not all address wires are decoded, so bank-switch registers may be shadowed throughout the $0000-$0FFF range.

Bankswitch style 3E, extended (32K EPROM + 32K RAM):

• Address $1800-$1FFF always access the last 2K of EPROM
  
• Write 0-15 to location $003F to select a 2K bank of EPROM to appear at $1000-$17FF
  
• Write 0-15 to location $003E to select one of the first 16 1K banks of RAM to appear for reading at $1000-$13FF and for writing at $1400-$17FF
  
• Write 0-15 to location $023E to select one of the other 16 1K banks of RAM to appear for reading at $1000-$13FF and for writing at $1400-$17FF
  
• Writes to even addresses $00-$3C will act the same as $3E, but will also affect Stella.
  
• Writes to odd addresses $01-$3D will act the same as $3F, but will also affect Stella.
  
• Use addresses $40-$7F to read/write to Stella without bankswitching.
  
• Writes to $0200-$027D will behave analagously to writes to $0000-$007D.

Bankswitch style x3D (new 32K EPROM + 1K RAM):

• Address $1200-$1FFF addresses one of eight 4K banks of EPROM. It is recommended that reset vectors be present in all to force a bank-switch on power-up.
  
• When RAM is enabled, address $1000-$10FF addresses one of four pages of RAM for reading, and $1100-$11FF accesses it for writing; otherwise that address range accesses the same EPROM bank as $1200+
  
• Write anything [data is irrelevant] to address $023D to enable RAM, or $033D to disable RAM
  
• Write anything [data is irrelevant] to $43D-$73D to select one of four 256-byte pages of RAM
  
• Write anything [data is irrelevant] to $83D-$F3D to select one of eight 4K banks of EPROM

Bankswitch style x3C (new 16K EPROM + 2K RAM):

• Address $1200-$1FFF addresses one of eight 4K banks of EPROM. It is recommended that reset vectors be present in all to force a bank-switch on power-up.
  
• When RAM is enabled, address $1000-$10FF addresses one of eight pages of RAM for reading, and $1100-$11FF accesses it for writing; otherwise that address range accesses the same EPROM bank as $1200+
  
• Write anything [data is irrelevant] to address $023C to enable RAM, or $033C to disable RAM
  
• Write anything [data is irrelevant] to $43C-$73C to select one of four 4K banks of EPROM
  
• Write anything [data is irrelevant] to $83C-$F3C to select one of eight 256-byte banks of RAM

Bankswitch style x3B (new 32K EPROM + 8K RAM, with restrictions):

• Each 4K bank of EPROM has four associated 256-byte pages of RAM
  
• Address $1200-$1FFF addresses one of eight 4K banks of EPROM. It is recommended that reset vectors be present in all to force a bank-switch on power-up.
  
• When RAM is enabled, address $1000-$10FF addresses one of 32 pages of RAM for reading, and $1100-$11FF accesses it for writing; otherwise that address range accesses the same EPROM bank as $1200+
  
• Write anything [data is irrelevant] to address $023B to enable RAM, or $033B to disable RAM
  
• Write anything [data is irrelevant] to $43B-$73B to select one of four 256-byte pages of RAM associated with the current EPROM bank
  
• Write anything [data is irrelevant] to $83B-$F3B to select one of eight banks for both RAM and EPROM

The first bank-switch method would require all three jumpers to be in the "A" position; the other three would require all three jumpers to be in the "B" position. All four methods would require the 22V10 to be programmed differently.

Anyone think that sounds like an interesting concept?

[batari]

supercat, on Thu Jun 30, 2005 9:54 PM, said:

I'm working on a minimal RAM+EPROM cart design which I'd open-source if anyone would be interested. 
...
Anyone think that sounds like an interesting concept?

Interested. Open source would be great - it would allow for people like me to see how you did things, and maybe even tweak the code for other purposes. That is, if you're using VHDL, since that's what I know. I don't know Verilog or how to use the schematic-level tools such as Delicon is using. Well, that's not totally true, I've messed with Mentor Graphics Design Manager and made a few simple schematic designs, but I'm not very good at it.

Also, it would allow me to modify your layout to use socketed parts, since I can't solder surface-mount to save my life. It would cost more, but would allow for hand-assembly for those of us with margnial eyesight and shaky manual dexterity.