Jump to content

wilco2009

Members
  • Posts

    24
  • Joined

  • Last visited

Posts posted by wilco2009

  1. Good evening folks,

    I wanted to tell you that I am no longer going to manufacture videopac cartridges.
    But don't worry, so that nobody who needs it is left without a cartridge, I have just converted it into OpenHardware, for this I have published all the information to make it yourself on github.
    It is released under the GPLv3 license, so anyone who wants to can make the cartridges and sell them to third parties, as long as the license is respected. In this way it is ensured that users who do not have the capacity to make a cartridge by themselves can acquire it by another means.
    I wish you enjoy it, and I hope you will modify and improve it.  http://videopac.nl/forum/Smileys/default/wink.gif

    https://github.com/wilco2009/Videopac-micro-SD-Cart

    • Like 4
  2. Here you have the translation. ;)

    fMsghdn4A4FvM5DLhH1yiNbthjFbb72DT-V4Z-pJ
    Hello guys!
    Some time ago I announced the next release of a Jupiter Ace clone that I am developing.
    The clone is currently fully operational and I'm only tweaking the last design details.
    It is a board fully compatible with an original Jupiter Ace case, using its rubber keyboard, although it is also possible to solder push-buttons and use these.
    The most outstanding characteristics are:
    - 19K or 3K selectable onboard RAM
    - 8 selectable ROMs
    - zx81-like mode (it's like you have a zx81 but 3 times faster in SLOW mode and keeping the display, the keyboard layout is automatically changed to match the zx81, and all with moderate compatibility with existing software )
    - test ROM
    - Selection of direct video mode (white letters on a black background) or reverse (black letters on a white background).
    Well, I'm exploring the idea of doing a kickstarter (in collaboration with Paul Andrews) that would include a molded plastic case and a rubber keyboard identical to the original, so it would be practically the same as having an original one in our hands but with the mentioned improvements. But, the molds for the case and keyboard cost a lot of money.
    We have requested budgets and the project is perfectly viable, as long as there is more than a minimum number of bakers, so before I get into it, I would like to probe your interest in a possible kickstarter, and ask you to answer these questions:
    - Would you be interested in buying one?
    - How much do you think could be a reasonable price? (You already know that the total expenses must be passed on to the units sold, so if we are too few it can be too expensive and unfeasible.
    - Do you already have a Jupiter Ace and want a replacement case, keyboard or PCB?
    - Do you prefer to assemble a kit yourself?
    You would do me a great favor if you filled out the survey by clicking on the link.
    https://forms.gle/3kcrRm2V8swirYVm7

    • Like 2
  3. 10 hours ago, carlsson said:

    So did the original C7420 use a Z80 version of BBC BASIC or was that Gert's choice of dialect when he implemented it 10 years ago?

     

    Edit: Ok, it was his choice of dialect as the original one has (c) Microsoft and for certain Acorn and Microsoft never were the same.

    Here there are a picture of my original cart C7420.

     

    MUNKIsRXh2O2jjZHrwl2OJMqfZNZDKlqPSzid0qj

     

    The look and feel is exactly the same as far I have seen, and the ROM content is also the same, except for a patch of two bytes made by Gert to implement the simulation of the tape with the SD reader.

     

    • Like 1
  4. With the original author (Gert van der Knokke) permission I have recreated the C7420 BASIC Module :)

    YSVrWKPZ1mwClN8UKSCOiNUzI3ibzYpvSEJHGV35

    https://www.youtube.com/watch?v=w5BvdcZ9Cn8

    I have used a cheaper microcontroller than the original one selecting a STM32F4VG.

    And the result is really great. :)

    I like it a lot!

    Now I have to finish some details with the SD to save/load BASIC programs, and design a final PCB to fit in a 3D printed case. 

    I have permission from Gert to assembly a batch and publish the source code, due to it when I'll have everything finished I will start a list.

    NOTE: I still have intention to make a exact clone, but this is for a near future. ;)

    • Like 4
  5. 2 minutes ago, jimj said:

    Assuming you've got the files on the zip card ok you should be able to just plug it in, turn on your O2 and it loads the game selection menu.

     

    So far I've only used the ROMs that are included in its zip file, I haven't tried loading my own ROMs yet.  It's not clear to me if I need to edit the ini file manually to make new ROMs playable or if that will get built automatically.

     

    Yes it is not necesary because the autobuild option is active by default (see user manual). If it is not active, after adding the files you have to rebuild the directory from the config menu.

    In general it is not necessary to modify "gamelist.ini" in any case. This file is just to add descriptions and to assign special pagination modes.

    The file is ready for all the known games.

     

    • Like 2
  6. It is currently out of stock.

    I have to order parts to build more cars. It would take 30-40 days to arrive from China. If you want I can add you to the waiting list.

    43 minutes ago, AdamO said:

    wilco2009 - I would like to purchase one with the SD.

     

  7. 27 minutes ago, jimj said:

    Don't know how I missed this on videopac.nl.  I'll take one (no microSD card needed).  How do I pay?

     

    Now I am waiting for more components.
    I think I will have everything in 20-30 days.
    I'll let you know when I have everything ready.

    • Like 2
  8. 2 hours ago, Kroko said:

    If you have two different drivers on the databus, are you sure that the console will not get damaged ? What happens if both drivers

    set different values ? Are 2600 databus drivers protected against such situations, where they have to drive the bus "against" a second

    driver ?

     

    It could be a problem in a CMOS CPU, because it uses strong "1's". In this case if you force 0V while the data line is at 0V the power will be dreaned in the data pin generating a high current with possible damages in the data pin of the processor.

    The 6507 Atari's procesor uses NMOS technology. NMOS technology has strong 0's but weak 1's, then it is not dangerous to force a data pin to zero.

  9. 8 hours ago, batari said:

    I thought I might add that there *might* be a very simple, if somewhat unorthodox method that could keep the console busy without crashing.

     

    Atari themselves designed hardware that overrode the data bus, and in doing so, maybe you could keep things running just long enough to boot your hardware. Atari did this with their Graduate add on, which they called bus stuffing, and also there is a cart out there that predates this called the Signal Tracing Cartridge which basically just throws an $EA on the data bus through a series of pullup and pulldown resistors, overriding anything that the 6507, TIA or ROIT attempts to put on the bus.

     

    Thinking about this, though, you are asking how to reset the console from the cart port: well, you can't, but the only reason you would need to reset is if the 2600 hits a JAM instruction, which are basically the only instructions you can't recover from. These instructions have a pattern of D1=1. So technically, all you might have to do is drive D1=0 until you have some valid data to present, then issue a BRK and you could probably reliably boot the console.

     

    Mmmmm, very interesting, seems to be easy to do. ?

     

    Thanks very much. 

  10. 38 minutes ago, batari said:

    Another option is to write a short wait routine that runs in the console RAM until the data from the SD card is loaded. This is how the Harmony Cart handles it. With only 128 bytes you can't do much, but with creative programming you can actually display something on the screen in this little of space.

    But how do you prevent the console from hanging until you copy these 128 bytes into RAM?

  11. On 7/1/2020 at 11:02 PM, Kroko said:

     

    You can not let your cartridge provide random values on the databus, you need to make sure that you keep control over what is going on.

    If the console shows some address on the bus, which is located in you cartridge, then you need to output something that makes sense.

     

    You need to construct your cartridge such, that some initial ROM is presented to the console.

    This can be a very simple ROM (only a few bytes). Or a very complicated one. Some cartridges provide a "menu system" ROM to the cartridge until they
    finished loading the real roms. Or they let you select one of several different ROMs that the cartridge can provide. After finishing the loading or selection they

    all have the same problem: to do a clean start of the ROM they loaded. This can be done by presenting a JMP ($FFFC) instruction to the console.

    Starting from that moment, the real ROM must be provided at the databus and the initial ROM is switched off.

     

    An example of a very easy initial ROM would be a reset and IRQ vector pointing to $1000. And a BRK instruction at $1000. This will result in an endless

    try of the console to jump to $1000. I think these are only 5 bytes you need to provide to the console while you are waiting for your SD content to load.

     

    After you loaded, you wait until the cartride provides $1000 at the adress bus and you provide the JMP ($FFFC) instruction instead of the BRK. Then you switch
    in the real ROM. I did not try this, but maybe somebody else wrote code like this before. You can also make some endless Loop ...important is only you have

    control over what the console is doing, while you are waiting.

    Thank you very much for your explanation.

    Then seems the best solution is to add a little EROM chip to the circuit to take the control until the cartridge tranfer the program to the RAM chip.

    Another posibility is to send bytes to the bus from the CPLD without any kind of ROM in the cart. The main issue is the sincronization when the change to the RAM is made.

  12. Hi!

    I'm trying to design my own sd cartridge for the Atari 2600 console, but to read the rom from the sd card take some time, and while it is happening console is running random values in the memory, and when the memory is ready console is already hung.

    Anybody knows how is possible to generate a reset in the console from the cartridge?

    thanks in advance

×
×
  • Create New...