Jump to content

Recommended Posts

Hi all!

 

Last month I saw the following ad on eBay:

 

1660976102_eBayAd.thumb.png.dedd29e38aaac4334868c2d3b7a9448e.png

 

I thought the appeal of this kit for homebrew development was very limited:

  • No bankswitching/mapper (only 2K games or 4K games with further modifications on the board)
  • It required messing around with UV lamps, programmers, etc
  • Required some knowledge of electronics
  • Buying the parts separately would probably be less expensive
  • Not possible to ship as a product to customers

 

It would be probably easier and faster to use one of the existing USB/SD carts to test on a real hardware.

 

This did make me think though that I had never seen a development kit for the 2600 which would allow homebrewers without knowledge of electronics to self publish their games.

 

If a mapper is required, then that knowledge need goes up real fast.

 

As in Europe we have very limited offers of good homebrew games available (most of them are from the USA and shipping quickly becomes a problem), I thought about making this my next project.

 

The idea is to have blank carts (populated with all required components but without any game image in them) and a simple to use cable and PC software which would allow the user to create a cart ready to be shipped to customers as well as test games in a real atari.

 

Is this something that would interest the homebrew community?

 

Here are some requirements I have come up with:

 

  • The final product must cost under 10€ (populated cart PCB)

  • All components must be easy to find.  Preference should be given to components still in production

  • Must be usable by people with no experience in electronics

  • No soldering

  • Must support mappers (the ones used by batari Basic at a minimum, as a lot of people seem to use bB)

  • No physical alterations to select the desired mapper (or no mapper)

  • Must fit in a standard Atari cartridge case

  • Components should be SMD to keep production cost as low as possible

 

All comments will be appreciated!!

 

Cheers.

  • Like 1
Link to comment
Share on other sites

I have Sebastian Kotek for designing the boards (he's mostly familiar with the 5200 and 7800) and Jerzy (Retronics, mostly Atari 8bit computer and PC line) for publishing the games. they are both from Poland. The real problem is that Jerzy does not want to use used plastic shells for games, the others are mostly easy to be produced. My last information is that he ordered the mold from China, but the production was held because of the COVID-19 story.

  • Like 1
Link to comment
Share on other sites

4 minutes ago, MemberAtarian said:

I have Sebastian Kotek for designing the boards (he's mostly familiar with the 5200 and 7800) and Jerzy (Retronics, mostly Atari 8bit computer and PC line) for publishing the games. they are both from Poland. The real problem is that Jerzy does not want to use used plastic shells for games, the others are mostly easy to be produced. My last information is that he ordered the mold from China, but the production was held because of the COVID-19 story.

Which bankswitching do you normally use?

Link to comment
Share on other sites

37 minutes ago, MemberAtarian said:

I used two of them, the F4 (32K Atari bankswitching) and the FE (64K) with SARA support. I tried to narrow things so Sebastian does not need to create too many type of boards.

Thanks.  That already starts narrowing it down ?

 

When you say FE (64K) do you mean Activision FE?  Do you use F4 also with SARA?

 

Cheers.

Link to comment
Share on other sites

13 hours ago, vcsrocks said:

Thanks.  That already starts narrowing it down ?

 

When you say FE (64K) do you mean Activision FE?  Do you use F4 also with SARA?

 

Cheers.

Sorry, I wrote it wrong, it's called EF bankswitching. :D And with the superchip RAM added, it should be called EFSC. :)
The other, F4, is the common 32K Atari bankswitching method by Atari Inc., with no SARA added.

  • Thanks 1
Link to comment
Share on other sites

1 hour ago, MemberAtarian said:

Sorry, I wrote it wrong, it's called EF bankswitching. :D And with the superchip RAM added, it should be called EFSC. :)
The other, F4, is the common 32K Atari bankswitching method by Atari Inc., with no SARA added.

OK, got it ?

 

I will go with the working assumption that the cart will support F8, F6 and F4 for now.  Last night I ran some queries on my ROM database and 90% of the games I have images for use one of the three schemes or no mapping at all.

 

SARA will depend on the hardware I end up with having RAM to spare.

Link to comment
Share on other sites

Started looking into what components to use for this.  I will need an inverter for A[12], the bankswitch controller and a communication protocol to download the image from the PC into the ROM.  The bankswitch controller must also be able to save the bankswitch selection in some sort of permanent memory.

 

This pretty much excludes most inexpensive CPLD candidates as they would not be able to retain the bankswitch configuration.  One option would be to have configuration jumpers though.  If they are not SMT however, it increases a lot the assembly cost.

 

I also looked into ARM processors (e.g. like the one used by the UnoCart) and FPGAs, but that would likely blow my requirement to sell the final product under 10€.

 

So I am left with 8 and 16bit processors.

 

The price constraint will probably play a significant role in this, so I will start small and go up until I find the cheapest solution.

 

From what I have laying around, I selected a PIC18F26Q10 for the POC.  They run at 16MIPs which gives me 62.5ns per instruction cycle, so let's see how far I can get with that.

 

Anyone out there with experience in implementing bankswitch in a Microchip PIC or any other 8bit MCU??

Link to comment
Share on other sites

21 hours ago, vcsrocks said:

Hi all!

 

Last month I saw the following ad on eBay:

 

 

I thought the appeal of this kit for homebrew development was very limited...

  • Must support mappers (the ones used by batari Basic at a minimum, as a lot of people seem to use bB)

  • No physical alterations to select the desired mapper (or no mapper)

  • Must fit in a standard Atari cartridge case

  • Components should be SMD to keep production cost as low as possible

 

All comments will be appreciated!!

 

Cheers.

Hi vcsrocks this is the definitely right forum for your thread.

 

The dev kit sounds excellent because you can create 2K and 4K carts and produce them farily easily.

 

If you want full support for BASIC it gets very difficult -

 

A Harmony cart supports all of the mappers for bB games using a complex setup with an ARM.

 

The UNO cart is another BASIC player that tubocharges the SuperCharger, enabling 9 MB of BASIC goodness or a 1.5MB compiled BASIC file specifically. 

 

Nobody is putting that on an EPROM anytime soon it's the theoretical limit but it's a cool to see the technology implemented to turbocharge the BASIC mappers.

 

MemberAtarian and Sebastian have a very realistic approach to enabling large 64k games with SARA support. This approach should not even require an ARM from the engineer to implement.

 

Many amazing games can be developed with the kit you posted - 4K is alot of fun in BASIC or Assembly :)

 

  • Thanks 1
Link to comment
Share on other sites

46 minutes ago, Mr SQL said:

Many amazing games can be developed with the kit you posted - 4K is alot of fun in BASIC or Assembly :)

Thanks Mr SQL!!  That's very encouraging.

 

I will wire up a PIC18 proto on the weeked.

 

Let's see how far I can get ;-)

  • Like 2
Link to comment
Share on other sites

7 hours ago, vcsrocks said:

I also looked into ARM processors (e.g. like the one used by the UnoCart) and FPGAs, but that would likely blow my requirement to sell the final product under 10€.

 

You can find the STM32F407VGT6 breakout board at AliExpress for about 6.50 USD, with a custom breakout board, like the PlusCart PCB the STM32F407VGT6 fits nicely into a cartridge.

If you leave away the ESP8266 you can easily stay below 10$ And you can reuse UnoCart and PlusCart code to support some additional bankswitching  


Assembly_4.png
 

  • Thanks 1
Link to comment
Share on other sites

5 hours ago, Mr SQL said:

Many amazing games can be developed with the kit you posted - 4K is alot of fun in BASIC or Assembly :)

Mostly I use up 32K of ROM because the music I do takes a lot of space. :D But my Fortari2600 plans will support only 4-32K carts (with the option of SARA), 64K is really a bit overdoing it.

The biggest advantage of 4K games is you can't create buggy jumps while bankswitching. :D

  • Thanks 1
Link to comment
Share on other sites

20 hours ago, Al_Nafuur said:

You can find the STM32F407VGT6 breakout board at AliExpress for about 6.50 USD, with a custom breakout board, like the PlusCart PCB the STM32F407VGT6 fits nicely into a cartridge.

If you leave away the ESP8266 you can easily stay below 10$ And you can reuse UnoCart and PlusCart code to support some additional bankswitching

Danke Al_Nafuur!!

 

That sounds like a good solution.

 

I have already started with the PIC18 solution, so I'll see where that takes me first.

 

I also like the challenge of creating a functional mapper controlled by an 8bit processor as I've always been told that it is not possible ?

 

Cheers

Link to comment
Share on other sites

19 hours ago, MemberAtarian said:

Mostly I use up 32K of ROM because the music I do takes a lot of space. :D But my Fortari2600 plans will support only 4-32K carts (with the option of SARA), 64K is really a bit overdoing it.

The biggest advantage of 4K games is you can't create buggy jumps while bankswitching. :D

32 and 64KB should not be a problem.  I found the description of EF but could not find any images to test it.  Do you have one you can send me or point me to?

 

On 3/27/2020 at 1:50 PM, Mr SQL said:

The dev kit sounds excellent because you can create 2K and 4K carts and produce them farily easily.

I have created a prototype board:

 

Front.thumb.jpg.1b6d759db1c45022c16d8be2f1559eca.jpgBack.thumb.jpg.f4319515685d1d206ada2eb69c214d6e.jpg

 

Now I will be working on the firmware..

 

2 and 4KB games will not require any active participation from the MCU except for the A12 inverter so I will start straight with Asterix (F8) and move on from there...

  • Like 3
Link to comment
Share on other sites

UPDATE:

 

The firmware seems to work fine for Asterix.  I will be testing a few other games but one obvious problem at this point is the EPROM I picked for the prototype.

 

It works fine for F8 and F6 but it is too small for F4 and EF.  It is also too slow (300ns) which significantly narrows the switching window the MCU has.

 

Last but not least, it breaks most of my requirements, so I will look for a replacement more likely to be usable in the final product.

Link to comment
Share on other sites

4 hours ago, vcsrocks said:

UPDATE:

 

The firmware seems to work fine for Asterix.  I will be testing a few other games but one obvious problem at this point is the EPROM I picked for the prototype.

 

It works fine for F8 and F6 but it is too small for F4 and EF.  It is also too slow (300ns) which significantly narrows the switching window the MCU has.

 

Last but not least, it breaks most of my requirements, so I will look for a replacement more likely to be usable in the final product.

The PIC18F26Q10 has 64kb flash and 25 I/O Pins? Maybe that is enough to do the job for simple bank switching up to 32Kb without a EEPROM ?

  • Like 1
Link to comment
Share on other sites

8 hours ago, Al_Nafuur said:

The PIC18F26Q10 has 64kb flash and 25 I/O Pins? Maybe that is enough to do the job for simple bank switching up to 32Kb without a EEPROM ?

That would be the best solution, but it is not possible even if bankswitching is completely left out.  In the VCS, the 6507 expects the data bus to be stable about 400ns after the address bus is setup.  The PIC18F26Q10 needs 62.5ns per instruction cycle, so that translates to about six instructions to do the following:

  • Detect an address change.  As the communication between CPU and ROM is asynchronous, the MCU will have to detect a change in the address bus to start decoding it.  The fact that the address bus is 13bit long (A[12:0]) and the MCU data bus is 8bit further complicates things.  That could potentially be done with IOC but it will still cost between two and four cycles if IDLE mode is used.
  • Control the data output state.  There are two separate registers involved in fully implementing tri-state in a PIC18.  That would already take at least three cycles.  The MCU has configurable open drain outputs, which could help though.
  • Fetch the data from flash.  This is the killer.  It takes a minimum of six cycles to read a PFM location (i.e. four cycles to set the pointer and two cycles for the actual read) and another two cycles to output it to the port.  There are other methods to read PFM, but the net cost is always equal or higher than this.

So at best we are at 11 cycles which will not work.

This would go towards a STM32 solution or at least a fast 16bit MCU.

If the PIC18 does not work, than the option is back on the table, but if the PIC18 works in conjunction with an external ROM, the overall cost will probably still be lower than going with a more powerful MCU.

  • Like 1
Link to comment
Share on other sites

After some digging I found an old stock of flash memories I have which are still available for purchase in most reputable online stores at a fairly good price.

 

So here is the new prototype:

 

20200331_143706.thumb.jpg.4094025251ce3a5ac1ece0007b714f6e.jpg20200331_143732.thumb.jpg.9f66aced34cab00af805d1a4232ac58c.jpg

 

I tested Asterix again and it works fine, so I will be testing some more games to cover all schemes.

 

But as the saying goes, every time you solve a problem you create another one.  In this case, the memory I am using is too big!  It has 256KB which for 2600 standards is a waste.  I will see if it is viable/worth to make this a configurable multi-game cart (i.e. it can be configured as a single game or multi game cart depending on what is being published).

 

  • Like 2
Link to comment
Share on other sites

I've managed to test the following games with the new prototype:

  • Sword of Surtr (F4)
  • BMX (F6)
  • Asterix (F8)
  • Pacman (4K)
  • Air-Sea Battle (2K)

I was able to play the games for as long as I wanted with no glitches, so that tells me the firmware is working (at least for these particular games).  I also checked the ROMs in Stella to figure out when the game does the backswitching and make sure I hit that point of the game multiple times.

 

I still need to find an EF ROM to test and then perform the following additional tests:

  • NTSC console.  So far I have tested on a PAL console but the NTSC version is slightly faster, so I will be testing this too
  • 7800 console, as it has completely different timings at start up which may confuse the firmware
  • More games to make sure the solution works every time

I am also working on a solution to switch the games on a multi-game ROM image.

 

Stay tuned ?

  • Like 2
Link to comment
Share on other sites

On 4/2/2020 at 9:02 PM, Al_Nafuur said:

I like your breakout PCB, where did you get these from?

 

After years of dealing with jumpers and re-purposed old cart PCBs I decided to have these made at the end of last year.  The idea comes for a similar board I've seem somewhere for the MSX.

 

They really help as there are no more bad connections or jumper cables getting disconnected and driving me craze for hours (or days as it has been the case more than once).  The lined up address and data connectors make general debugging and analysis (e.g. with a logic analyzer) a lot easier and the A12 inverter saves wiring and board real estate.

 

They were definitely not cheap, but all in all the amount of time they have saved me since I got them is paying.

 

On 4/2/2020 at 9:02 PM, Al_Nafuur said:

There is a multicart project for the XL/XE with an quit similar approach like yours.

 

That looks quite good!  I guess the two main differences is that they went the CPLD route, which is much more straight forward but a lot more expensive as a final product; and you have to use an standard programmer for the ROM which makes it a bit more difficult and intimidating for people without practice.

Link to comment
Share on other sites

Not a whole lot of time to play with this over the weekend, but I did manage to test the EF scheme and it works fine on the prototype. :thumbsup:

 

So the current list of schemes confirmed to work are: F4, F6, F8 and EF.

 

So I will be working on the multi game selection now...

  • Like 1
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...