5-11under

Cool story. When we coded ZX81 games in assembler, it was pretty similar... write the assembly on paper, figure out the machine code, put that in a DATA statement, write a routine to move the data to REM statement at the start, and then run the code. Of course I was about 16 and not 11 at that point, and the games were very small at maybe up to several hundred bytes... there's pretty much no way I could have done what you did at age 11, even if the computer was avialable.

Once this is solved, especially if it's a set-up or speed or timing issue (or anything obscure, or limitations to the console), it would be great to understand the exact problem and solution. Thanks!

I was wondering about that. 1982 seemed a bit slower than usual (or maybe the jets aren't coming straight towards you as much, when traveling mostly in one direction).

Quick update: the initial shell prototypes arrived. I've got a lot of minor modifications to make to the design, and hopefully in a few weeks or so I'll have new pieces in hand that fit like a glove. All other assets are fully designed and figured out as far as production goes. Most recently the keyboard overlay, the screen overlay, and the cardboard insert that holds the game in the box (sorry, no foam at this point). I also designed the box bottom, which I didn't have prepared before. Barrage 2021, 2022, and 2023 are dead ... ... ... Long live Barrage 2024!

I had a bit of a delay in ordering, to line up some money, so these should arrive hopefully early March or so.

It should work on most Intellivisions. I know sfish is having similar issues, with a similar console (and regardless of delays.txt tweaks), but have you tried any other settings for the delays.txt file, or not? If not, it's a simple task to reduce (or increase) one or both of the numbers by 20 or 40 or so, to see if there are any improvements. The good news, for you, at least, is that it looks like this is going to be a very limited edition, so I'm guessing someone might jump at buying it, and giving it a try for their console.

No update from me, yet. It's still on my to-do list, though. For future club games, that depends on game size, in the least. I also anticipate the boards to be fixed at that point.

I should have more available in a month or so.

The shell is ready for a prototype. No use working on the last couple of percent until I get a couple of samples printed: All printed assets were also finalized, including box, manual, label, keyboard overlay. Game renamed, again, to Barrage 2024. Here's part of the box:

Just rename the .int files to .bin files. The RTO needs .bin files (and .cfg). You don't need to add these extra files. They won't do any good. Nowhere in the code or the instructions does it refer to any of these files.

@Crash7 What are the contents of the delays.txt file? Have you tried alternate values lower or higher? The details are important, and as mentioned, the default delays.txt file I provided should work exactly the same as if you didn't have the file there at all. You need to change the numbers for any changes to occur. BTW, "colored screen" or "patterned screen" is descriptive enough in most cases, unless you're getting something that resembles the game

First of all, the INT files need to be renamed to bin files. You need bin+cfg files (or 0.cfg for most classic games). You don't need the .ino and .h files, but they're okay to stay. Does the RTO display show appropriate responses, such as boot-up credits, then the "press a button" message, and then showing folder items, and showing "Active ROM" when a game is selected? On the TV screen, after the boot-up credits, the console should reset, and show the RTO splash screen. If you get to the "Active ROM" point, the game should play. So, make sure you have the bin files instead of int files, and then try it out, reporting on the steps you're making, and the results on the RTO display and TV screen.

The firmware has been loaded into the Teensy. If you see proper/appropriate messages on the RTO display, then that aspect is likely working fine. The SD card typically only needs bin and cfg files, with the same root name, such as blackjack.bin and blackjack.cfg. aotta also posted a 0.cfg file. That is the default cfg file that would be used, in case there is no blackjack.cfg file on the SD card, for example. So, for most classic games, all you need is a few bin files and 0.cfg file to start with. 0.cfg should be in the root folder. Games can be in the root, or one level deep into a folder. Besides 0.cfg, bin and corresponding cfg files should be in the same folder. Beyond that, there's the option to add a delays.txt file in the root folder, as discussed over the past couple of days.

What sets of values have you tried for the delays.txt file? Was the file format correct - just one number per row, followed by a return?

The console resetting should be automatic, but does it work any better if the console is reset manually at boot-up and after game selection?

Wrong thread reply.

Um, how about "482 for delRD and 540 for delWR"? Honestly, I don't have much of an opinion on this myself, but others have done some experiment on this. All I really did was add the "delays.txt" file capability, so you just have to edit a file if straying from the default, instead of having to recompile the code in Arduino.

Also, search for "delWR" or for "delRD" to find posts related to the delay timing values.

The delays.txt file would require a change in the numbers to make a difference. Using the default numbers wouldn't change anything.

First of all, create a file named "delays.txt" and put that in the root folder of the Micro SD cart. Add the following lines to the file: 520 565 Alternately, see the attached txt file. These are the defaults for delRD and delWR respectively, so the cart will work the same with the numbers 520 and 565 compared to not having the delays.txt file at all. That said, this method does make it relatively easy to try different delRD and delWR values, just by editing the delays.txt file, and restarting the console. There's information in this thread and other RTO threads regarding alternative numbers that could work. Perhaps there's also some newer best practices for that. I haven't checked lately. I've also attached the .ino file that all these particular RTOs are compiled and loaded with (and the original splash.h file). There may be more assets required to compile the .ino file... but for now, at least, you can see what's happening in the code. delays.txt RTOCart-HD-107.ino splash.h

I'll add some additional information tonight.

I'll provide some additional documentation for this version either tonight or tomorrow. The code has links to a "delays" file that can be used to change the timing parameters.

The "map" argument can take on one of two values: 16K or 42K. This selects between two memory maps: 16K: SEGMENT RANGE 0 $5000 - $6FFF 1 $D000 - $DFFF 2 $F000 - $FFFF 42K: SEGMENT RANGE 0 $5000 - $6FFF 1 $A000 - $C020 2 $C022 - $FFFF 3 $2000 - $2FFF 4 $7100 - $7FFF 5 $4800 - $4FFF The 42K map also includes some additional RAM from $8040 to $9EFF. You've got ~10.5 4K blocks in the list... 42K. Adding 8 and 9 gives ~12.5 blocks, or 50K.

From the Cart-mac info: "The 42K map also includes some additional RAM from $8040 to $9EFF" - this space can be set up as ROM space, so you've got closer to 50K words. I think this is supported in most solutions.

Sorry, I'm not sure exactly what the point is (maybe I'm misunderstanding the "with all do respect" followed by the "but" conjunction). I'm reading the legacy games were about 98.6% working, and with modern releases we're getting potentially less success, but with added complexities such as old VRAM, old power supplies, dirty power switches, SGM, games > 32KB, games with EEPROM, Phoenix, F18A, DIY consoles, and more.