SvOlli

October 5

Also, I can tell you, how it works with the SARA extra 128 bytes RAM.

This chip is just put alongside of the ROM (or in my case EPROM+GAL). It has full address decoding, so it can select itself, what to do.

For the ROM side, you just put $FF in the first 256 bytes of each page, so the bus is "virtually untouched", since it's open collector and the "0"s drive the bus.

September 15

5 hours ago, bfollowell said:

It also shows over 134 million bytes, not bits, so I was correct that it is reporting it as 128 Megabytes. It's just misreporting it for some reason.

A simple, though not 100% accurate explanation: the RP2040 uses a fake FAT16 filesystem. If you try to copy anything else but an uf2-file, the copy will fail. But to make sure that no tool can falsely assume a FAT12 filesystem, a size is reported that too big for FAT12 to handle.

It's like those fake USB thumb-drives from China: it reports more capacity than it actually has. Only in this case, for a good reason. ;-)

September 10

4 hours ago, Windless said:

Makes me need to improve my own plasma-ish effect before I dare releasing it

Well, I wanted to quit this idea about four times until I got something that I was okay with. It wasn't fully what I had envisioned, but it got rather close, and I'm not sure that my original idea would have made a difference, visually.

September 10

Hello everyone,

just wanted to let you know that I released another 512 bytes demo. This time the focus is on trying to get a rather good looking plasma effect using a "feature" of the 2600 to our advantage: mirrored playfield. However, to squeeze more bits in one line, I'm also using sprites at the sides.

The platform used is CommaVid, so I can pre-calculate some data. There is also a version running on SuperCharger available, but since RAM access there requires more effort, so that version is more that 512 bytes in size. It won a rather surprising second place in the 512 bytes compo. Ah, and you can also use the color / b/w switch to go back from the colorful mode to the monochrome one from the beginning.

The homepage of the demo is https://xayax.net/raw_shark/. You can also watch the demo in the browser thanks to Stellerator.

The name is a pun on Rorschach, which was using in the comic that inspired this demo.

August 5

On 8/4/2023 at 3:32 AM, Himeno said:

Can the 2600 Board be used of the 4mb and 16mb picos or only the 800 Version?

It's not as much about the size of the flash, but rather the pinout of the board. Educated guess, from what I know about tinkering with different Pico Clones: what's sold as 4MB should typically work, as the differences I encountered so far were about the pins 3V3_EN and VSYS. So those should work.

The 16MB boards I bought so far, were using all 30 GPIOs of the RP2040, so those won't work, as adapting the software to the new layout would slow down the handling of the I/O to a point where I just won't work. Nevertheless, if the PCB design is released adapting the "adapter board" to the new pinout should be rather straight forward.

On 8/4/2023 at 3:32 AM, Himeno said:

Anything New about it or where to geht the boards?

As stated in the thread about the Atari 8-bit version of this cart, @electrotrains has some health issues slowing him down at the time. So "gute Besserung" from Germany.

July 21

Hello!

There is an idea that I've been tossing in my mind back and forth for a couple of months now.

In the 80's there was a 2600 development system available for the Apple ][.. But it's hard to find information about this except for some scans of adverts.

So I want to use this thread to collect as much information as possible about this development system. Mostly I'm interested in the software (disk images, archives, source code, etc.) and pictures of the board.

My final goal would be to recreate the board as an open source project (or a similar board from scratch) that will work with my Apple IIgs. What do you think, would this be achievable?

July 20

How about releasing the source code for someone else to pick up?
There's no guarantee that this will happen, but still there is a good chance...

July 20

On 7/18/2023 at 8:57 AM, john_q_atari said:

The 2600RGB isn't a silver bullet as more than a few 2600 games don't have a stable scan line count. When connected through the 2600RGB to a converter/display this manifests itself as the display losing sync for a moment and the picture blacking out for a brief moment. At least it does for me and it is a bit inconvenient.

There are even more problems: the sync signals are the original ones and those are not perfect either. Also the FPGA has a problem in some corner cases, triggering a register change too late, when being accessed using STA $ZP,X.

July 16

Thanks!

Being a 2600 demo coder, this is definitely something that I want to try: a 2600 compatible machine that adds an ACIA, ROM for terminal software and some GALs for expanded address decoding, so a you could either get a machine with 63k of RAM also capable of running 2600 games.

But since there are also other project in the pipeline, I doubt it will happen within the next months...

July 16

Hello!

In the last two months, I've created a self-built computer based upon the 65C02 and a RP2040 microcontroller only. Everything including PCBs and all code is open source.

The idea was to have a very simple system to teach about how the 65C02 works, as well as a platform to build very simple machines like the Apple Computer 1, which can already be mimicked. A bus system ensures that it's open for expansions.

An intended to be growing webpage has been set-up at https://xayax.net/sorbus/, all code is available at https://github.com/SvOlli/sorbus/

July 15

If you'd like to take a look at a real world example generating a plasma effect.

In the source code:

the code that copies the the code from ROM to RAM is at the bottom at line 247
the code that's been copied is right above at line 225
the adjustment of the code and calling it starts at line 167

But most probably the best way to get an understanding is to run the demo in Stella, once the part is displayed, enter the debugger and step through the code.

July 13

On 7/11/2023 at 10:06 PM, splendidnut said:

Supercharger would be a good candidate for doing self-modifying kernels, with it's three 2k RAM banks available in the cartridge memory area.

I'm not so convinced about this, if you look at the end result and motivation. Typically you need self-modifying code for two reasons: size or speed (or both). Writing self-modifying code just because it's self-modifying is not a valid argument, as you want to improve your code or circumvent an obstacle using self-modification.

There are two ways to manipulate the SuperCharger RAM:

Option 1: without vector

Code:
$f100: cmp $f000,x
$f103: nop
$f104: cmp $f000,y

Bus access:
1: f100 dd
2: f101 00
3: f102 f0
4: f0XX __  <-- trigger and write XX to latch (don't care about __)
5: f103 ea
6: f104 d9
7: f105 00
8: f106 f2
9: f2YY __  WRITE XX now

Option 2: with vector

$f100: cmp $f000,x
$f103: cmp ($80),y

Bus access:
1: f100 dd
2: f101 00
3: f102 f0
4: f0XX __  <-- trigger and write XX to latch (don't care about __)
5: f103 d1
6: f104 80
7: 0080 00
8: 0081 f2
9: f2YY __  WRITE XX now

What happens there is on the write to the $f000 bank the low-byte of that address is stored into a latch. After the write to the $f000 bank a counter starts, counting changes on the address bus. On the 5th change, the bus will be taken over from read to write and the data from the latch will be written to that address. (A slight simplification, but it's enough for the explanation.)

This works awesome while loading from tape. It still works somehow for creating tables. It sucks when trying to create code. Why? Writing to RAM costs you both index registers that are typically required for generating anything, especially when code space and/or cycles are tight. When creating data tables it's already a pain. My 512 byte demos, when ported from CommaVid to SuperCharger are then >550 bytes. Take a look at the source code of both versions for generating the sine wave to understand what it means to "loose" index registers. It's very annoying. On the bright side: timing is no issue there, as the tables are only generated once.

When nowadays a 32k ROM costs roughly the same as a 4k ROM, instead of generating the code in the cartridge, generate the code during assembling in ROM. Way less problems: no microcontroller or else to emulate RAM, just a plain EPROM with GAL/PAL for bankswitching like it's been working for how many years now?

If you require self-modifying code it's typically just a snippet that you can squeeze into the 6532 RAM. If there's too much stuff in there, then you might be forced to use other RAM, but if it's SuperCharger better use it as swap memory. Having done tight coding with self-modifying code on the 2600 for more than a decade now, nothing else made sense. Not once, and - believe me - I've tried.

No code generation in SARA, no code generation in SuperCharger, not even in CommaVid. Why? Because of the zero page addressing, generating code in 6532 RAM costs you one byte less in ROM for each time you write to RAM.

I'd like to be convinced otherwise, though... But if I'd have to reimplement something like my favourite plasma effect again, I'd definitely go for 6532 RAM again, no other RAM for code generation.

June 29

The only way to detect this would be a blacklist with md5sum or something like that. Because there's no way by looking at address $FF8 of the ROM image if this gets touched at any time in the game. Running through some kind of emulation does not work also, since the address could be access only after 2 hours of gameplay in a specific situation.

June 29

35 minutes ago, Mr SQL said:

This is a cool utility, would be possible to add an option to patch the hotspot if the ROM breaks?

This is technically not possible, because there is no generic patch. If you take a look around the old entries in the forum where 2K/4K patching games for SuperCharger is discussed, you'll see that there are different approaches.

Let me take a 4k demo I did quite some time ago as an example: I "ported" that about half a year after the release to the SuperCharger. This was rather painful, as the demo was using every single byte of the ROM. So what I did: I asked Thomas Jentzsch, if he could free up a couple of bytes so I could add some code. That code did not prevent the bankswitching, but rather pre-configured the bankswitching to switch to the current bank, effectively doing nothing, once the hotspot has been touched. Not touching the hotspot was not an option, as the full ROM was used as pseudo random data similar to Yar's Revenge.

If you really want to use the SuperCharger to play your collection of 2K/4K games it might make more sense to modify the SuperCharger by adding switch to disable the hotspot. That was a common mod back then. But with something very cheap multicarts like the 2600PicoCart around the corner, I don't think it's a good idea, to "de-originalize" the SuperCharger, which has become way more valuable than an average 2600.

Also there might be a collection around from "back in the days". And I also like the sport of it having to patch a game you really want to play. This way playing the game turns into a reward for playing a meta-game.

June 29

If you take a look at my demos which are released as mp3[1][2], you'll see that the mp3s are ~31.5k. The original wavs are ~171k. If I remember correctly, the mp3s did work rather well with my SuperCharger. The encoding was done using command line "lame" with default parameters.

[1]https://xayax.net/the_mating_of_the_colorworms/

[2]https://xayax.net/gar_nix/

June 29

55 minutes ago, Gemintronic said:

I appreciate the earlier versions but DOS/Windows support is still very much something I can't break away from in my 2600 dev.

Windows support is still in, that's why I chose portaudio: it's multiplatform and supports Linux/Windows/Mac.

June 29

A couple of years ago, I did a clean-up of the makewav code. Removed DOS parts and added support for generating audio directly using portaudio. It's available at: https://git.h8u.de/Atari_2600_Tools/makewav.

May 28

On 5/27/2023 at 5:00 PM, E474 said:

But I'm struggling to find the same board on AliExpress with Wifi, 16MB and 30 GPIO pins, e.g. Purple Pico W clone. Can anyone with better search engine skills post a link?

I don't think that this is even technically possible. My assumption is that it takes 4 GPIO pins to connect the WiFi module using SPI. While the purple exposed those extra 4 pins, the Pico W uses them "internally" for the WiFi module.

May 25

On 5/24/2023 at 12:08 PM, SvOlli said:

For better connectivity: how about using a Pico W and run Wifi with FTP on the second core?

This is something that might have come across the wrong way. May suggestion about FTP was that I try to implement the additional FTP server. (At least if @electrotrains thinks that this should be possible, and would want to merge it, once I've established a stable fork.)

On 5/24/2023 at 5:54 PM, x=usr(1536) said:

At that point, it may be worth running Samba (or similar).

In fact... Regardless of the network filesystem or transfer protocol chosen, make it switchable. [...] then regain full use of the CPU.

About Samba: no. Just no. FTP is a rather simple protocol, easy to implement. Embedded FTP servers are already available as open source code. It took me 10 minutes to find a candidate that's worth trying to integrate. Samba is one hell of a beast that's hard to get right, and I couldn't dig up anything that might run on a Pico.

About making it switchable: why? Why do you need a dual core 133MHz CPU to run software to accommodate a game console designed in the 70s which runs at <1% of that clockspeed?

My idea is to let one CPU core handle the 2600 bus and the other one runs the internet connection. The only problem that might arise is that the FTP might slow down filesystem access of the simulation, or that FTP uses too much of the 264k RAM.

On 5/24/2023 at 1:07 PM, batari said:

Mine is GPIO0-12 for the address bus, and GPIO16-23 for the data bus. The reason I did it this way is you can use a byte load/store directly to GPIO16-23.

I thought that the PIO State Machine of the Pico was intended for compensating this kind of problems. (Well, one of the use cases.)

May 24

Nice project. It's also awesome to learn about the "limited 5V tolerance".

Would like to help testing, both 2600 and 8bit versions.

For better connectivity: how about using a Pico W and run Wifi with FTP on the second core?

January 12

@glurk: what you can do in this specific example is to have the "leftmost green" as playfield color. That way it will always be drawn at a starting pixel. Then use background color for the "leftover" green. This will get you a chance to put anything in "character boundary".

Alternatively, you still can use sprites to "smooth the edges".

For planning things like this, I've hacked up a tool called "fridgegrid", which helps to make up your mind (but doesn't generate code). In my example, I'm using it to draw 8 vertical bars, each 32 pixels and each with it's own color, only using COLUPF and COLUBG. Might help, might not.

January 6

1 hour ago, r_chase said:

If you port the buildroot-stellabox to Raspberry Pi

Als you already stated with your edit, the main target platform is already Raspberry Pi as can be seen by the configs.

1 hour ago, r_chase said:

add a feature where you can load ROMs from a USB

This we can implement together using something like udev.

But to be honest, I prefer a lan/wifi solution over a USB stick any day. I don't know, what your daily driver OS is, but you can go for a remote filesystem access solution on Linux, Windows and MAC. (Haven't tested MAC myself, but I'm sure there'll be something like an sftp-client. For Linux I prefer command-line tools like "rsync", on Windows I'm using "Total Commander" which works great for this purpose.) Then you can upload stuff to the "StellaPi" just using the file manager on your host machine. Also you don't have to figure out what to do to delete or move ROMs.

It's also the way I did it on my favourite handheld Stella system: the Steamdeck. ;-)

My suggestion is that you try it. If you get stuck somewhere, we'll figure out how to fix / expand stuff together. Step by step.

I've updated to the current LTS version of buildroot and just pushed the update. I also copied Stella to the external layer since it's easier to update this way, and we can also extract stella.pro instead of supplying it from the repo.

1 hour ago, r_chase said:

Way better idea than actual bare-metal imho.

I wouldn't go that far, but using buildroot should be less effort now, and make maintenance in the future easier.

January 5

I did something that went into the direction of the Retron 77 a couple of years ago:
https://github.com/SvOlli/buildroot-stellabox . This also boots up quite fast (not 4 seconds, though) and brings you directly to the Stella UI. The advantage of this is that you can also include some kind of upload ROMs mechanism, like an embedded ftp server.

If you want to go for bare metal, you should see if anyone before you has managed to get SDL2 running on Circle (or any other bare metal framework) and use that.

January 3

Short question: ever considered to switch from RAR to 7Zip?
Your RAR Archive: 19612325 bytes

7Zip with compression=9 and solid compression enabled: 2509095 bytes.

So that's about 87% saved.

November 21, 2022

Magicard is not SuperCharger. The way RAM is accessed is totally different. So the Magicard sortware will not work on a SuperCharger.

Profiles

Forums

Blogs

Gallery

Events

Store

Community Map

Posts posted by SvOlli