Jump to content
  • entries
    62
  • comments
    464
  • views
    85,017

4A50 -- IT'S ALIVE!

Sign in to follow this  
Guest

544 views

Although I may still make a couple more tweaks, I would say that anyone with a Cuttle Cart 2 can now safely start development on 4A50-based projects. Use the banking file in the previous blog entry.I don't yet have EEPROM support in the CPLD, but expect that I will soon. I have in-circuit programming working for DOS-based PC's with printer ports. On a Compaq Presario 2100 (booting DOS off floppy and running off a RAMdisk) it takes 38 seconds to program and verify the Archon demo in the previous post (which uses about a quarter of the flash). I would expect that if the flash were completely full it would take about two minutes.The biggest remaining question is whether I'll be able to have the middle and lower banks address all of flash, or whether each will be limited to half of it. At present, my cart works with them being able to address all of it, but if I have to add much logic to make the EEPROM work I might not be able to keep that feature. Note that the CC2 banking file in the previous entry does have that restriction.I'll try to get a few more boards done fairly quickly for developers to play with; who all is interested? Programming requires a DB25 connector, a 5x2 edge connector (0.1" spacing), five resistors, a +5 volt power supply, and a DOS-based computer with a printer port.

Sign in to follow this  


7 Comments


Recommended Comments

I'm interested. (I'm not quite ready to take out a second mortgage to pay for a CC2 :) )

 

For the cable, can you get the +5v from the parallel port, or do you need an external supply?

 

And are you using JTAG to program it?

Share this comment


Link to comment
I'm interested.  (I'm not quite ready to take out a second mortgage to pay for a CC2 :) )

 

Aw, CC2 is awesome.

 

For the cable, can you get the +5v from the parallel port, or do you need an external supply?

 

Probably depends how beefy your printer port is. Using a battery and regulator seemed better than expecting 20+mA from a printer port.

 

And are you using JTAG to program it?

 

I'm using boundary scan on the CPLD to program the flash, but with /OE and /WE wired to the printer port.

Share this comment


Link to comment
What would be the price of a game on one of these boards?  Who would assemble it?

 

Those things remain to be seen. If Albert could handle surface-mount stuff that'd be wonderful, but I suspect he'd probably rather not.

Share this comment


Link to comment
What would be the price of a game on one of these boards?  Who would assemble it?

 

Those things remain to be seen. If Albert could handle surface-mount stuff that'd be wonderful, but I suspect he'd probably rather not.

Surface mount stuff is beyond the abilities of the majority of hobbyists, myself included.

 

However, I can do PLCC, which might be a good compromise. Although a PLCC version would take up more board real estate and require additional cost due to the sockets, the tradeoff may be worth it to save the cost of having it professionally assembled, and may end up costing less overall.

Share this comment


Link to comment
However, I can do PLCC, which might be a good compromise.  Although a PLCC version would take up more board real estate and require additional cost due to the sockets, the tradeoff may be worth it to save the cost of having it professionally assembled, and may end up costing less overall.

 

Well, the surface-mount chips are PLCCs, but there are also a few resistors and caps and such. It might be possible to do the board as throughhole using a socketed PLCC for the Xilinx and trying to find DIP parts for the flash and RAM, but assembly labor would be substantial doing that also.

 

One thing I'm trying to decide for my next (and hopefully final) board rev is whether to allow the device to access 96K or 128K of a 128K flash chip. I just noticed that the 128Kx8 chips are actually cheaper than 64Kx8, so there's no reason not to use one. The issue would be addressing, since my Xilinx part is pretty full.

 

If I just wire A16 of the flash to A11 of the cartridge port, that would allow 96K of the flash to be addressed. 32K would only be addressible via the $1000-$17FF bank and the other 64K only addressible via the other banks. Because the memory is ROM, information could be duplicated in the upper and lower regions if code needed to be able to access it in multiple banking areas.

 

Increasing the bottom area to 64K could be done via one of two ways:

 

Way #1 which would certainly fit would be to use the I2C output latch to control A15 on accesses to the $1000-$17FF bank. This would be rather ugly, but would work.

 

Way #2 would be to expand the four-bit lower banking latch to five bits. This would be nicer, if it fits, but it would be tight.

 

My one concern with doing these things is that unless users always use 128K binary files (sorta ugly) the device programming the chip would have no idea which data would be accessed in the upper bank and which in the lower; it would thus have to program the same data in both. Certainly doable, but it would double the time required for programming (my nice laptop, running DOS, takes about 2K per second).

 

Would anyone be interested in 128K carts?

Share this comment


Link to comment
However, I can do PLCC, which might be a good compromise.  Although a PLCC version would take up more board real estate and require additional cost due to the sockets, the tradeoff may be worth it to save the cost of having it professionally assembled, and may end up costing less overall.

 

Well, the surface-mount chips are PLCCs, but there are also a few resistors and caps and such. It might be possible to do the board as throughhole using a socketed PLCC for the Xilinx and trying to find DIP parts for the flash and RAM, but assembly labor would be substantial doing that also.

Yeah, socketed through-hole is what I meant. Sure, professional assembly of through-hole stuff would be just as costly, but at least this way it would let more of us assemble everything at home.

My one concern with doing these things is that unless users always use 128K binary files (sorta ugly) the device programming the chip would have no idea which data would be accessed in the upper bank and which in the lower; it would thus have to program the same data in both.  Certainly doable, but it would double the time required for programming (my nice laptop, running DOS, takes about 2K per second).

 

Would anyone be interested in 128K carts?

Why not?

 

Anyway, using socketed chips (PLCC or otherwise) those of us with suitable device programmers (like me) could just pop the flash chips in and program them in seconds... right? Besides, a minute is not that long.

Share this comment


Link to comment
Guest
Add a comment...

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