Jump to content

SvOlli

+AtariAge Subscriber
  • Posts

    402
  • Joined

About SvOlli

Profile Information

  • Gender
    Male
  • Location
    Hannover, Germany

Recent Profile Visitors

10,039 profile views

SvOlli's Achievements

Moonsweeper

Moonsweeper (5/9)

332

Reputation

  1. Of course they are not. They lack the pins that are required for paddles. The paddles are connect to an analogue pin each.
  2. Me too. I heard it during the time I was doing research for a talk about home computers from 1974 to 1977. So, those machines where a QWERTY keyboard was optional. My best guess so far is the three part series with Bil Hurd, Jeri Ellsworth and Chuck Paddle. Part 1: Part 2: Part 3: Also taking a look at this page: http://retro.hansotten.nl/6502-sbc/6530-6532/tim-6530-004/6530-004-dissected/, it seems rather obvious. There are images which explain the functions of the areas on the die. The 1K bytes of ROM (plus mask for address decoding) is slightly larger than the 64 bytes of RAM. So should be easy to modify the design to drop the ROM in favour of doubling the RAM. And as far as I can tell, it looks like the 2600 design started out with a 6530 (the JOLT / TIM-1 system was used as the development kit) which was replaced later with the 6532. Edit: interesting side-note: there is another difference between the 6530 and 6532. The function of A4 to turn on/off interrupts has changed. So you need an inverter at A4 to have the same address layout for I/O and timer functions. So that's what every KIM-1 clone utilizing 6532s does.
  3. I've got a theory that's just a guess, but sounds plausible. I heard Chuck Peddle stating in an interview that the 6532 was a design (done by someone else) based upon the 6530. Since the 6530 needed way more address pins, the PB5, PB6 and PB7 were shared with CS1, CS2 and IRQ, respectively. So I think that there might be still some transistors left from the sharing of IRQ and PB7, that cause the different behaviour. CS1 and CS2 however were mask programmable, so those might have a more indirect influence than the IRQ. @JetSetIlly this also leads me to a question about your 6532 implementation. I've built a cheap computer by just throwing a 6502 and an RP2040 microcontroller (from a Raspberry Pi Pico clone) together. Could your 6532 emulation code work "standalone" in this environment running on the microcontroller? I'm still just considering options, I also want to take a look at Stella as well, but my guess is that it's very tightly integrated with the rest of the emulator. And yes, I know that I would need to port the code from Java to C.
  4. 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.
  5. 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.
  6. 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.
  7. 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.
  8. 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. 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.
  9. 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?
  10. 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...
  11. 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.
  12. 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...
  13. 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/
  14. 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.
  15. 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.
×
×
  • Create New...