ivop

Yes. This is my "fork" to compile on Linux. https://github.com/ivop/RastaConverter This is what I used for all my conversions in this thread.

Trackball, mouse, and tablet data cannot be send through an (emulated) USB keyboard. That would need a driver at the PC side. Joystick could be done though, as most emulators have a keyboard emulation of the joystick on, for example, the numeric keypad. A movement or trigger press can then be sent as those keycodes by the AVR.

That would be the way to go IMHO. Not that I know of, but it's a good idea. Boot from a cartridge, send keystrokes over the joystick port(s) to an Arduino, which emulates an USB keyboard (tons of libraries for that), and connect to the PC as a keyboard. With a proper cart, you don't need a display for the Atari, or anything else for that matter. Just a power supply.

Here's an AUTORUN.SYS version. It takes 40+40+8+6 = 94 bytes of the bottom of page six. The init code after that can be overwritten. Pressing reset, well uhm, resets the display list statusbar.atr statusbar.s

Here's both a top and bottom statusbar. That's 94 bytes at the bottom of page six. We could turn this into an AUTORUN.SYS, and save a bunch of BASIC token space Edit: the ; at the end of status strings is important, or it'll try to print a cursor on the next line, which is non-existent. Edit2: have a working AUTORUN.SYS now. Will release source etc... shortly. Working on a demo program. Must have been years since I've done so much BASIC programming test.atr

BTW I added line 10 so I didn't need to do that manually every time I checked if it was already working. If you leave it out, and only run line 20-80 once, you get the statusbar without a full reset of E:. It's a pity there are no width and height E: variables 😕 Otherwise, it would be ease to subtract 1 of the height, and only temporarily adding 1 while printing to the lowest line. That would be a low cost bottom bar. But alas. BTW2 note that the previous post does not overwrite anything of the original DL, even though the jump is wrong at the end. The first VBI will overwrite the ANTIC registers anyway with the contents of its shadow register. Looking into extending this to a top and bottom bar, but that would need to overwrite the $41 instruction at the end of the DL, and point back to somewhere on page 6, for the extra DL line and 40 bytes of screen memory.

Here's plain basic. It takes 48 bytes on the bottom of page zero six. Edit: during sizecoding preparations, #Fready recently discovered that a DL jump also generates a blank line, which looks nice IMHO test.atr

Sure, that's how the player eventuallywill be used, without the VU meters, etc... Two downsides. One, you need RAM for the LZSS compressed data. Two, loading and saving through SIO will mess with the music.

Yes, it was just an example of what could be done (I sound like emkay now ). This can never be in-game music, but possibly during a title screen. Less CPU hungry, but still 5 channels, could be RMT2LZSS plus a low frequency 1-bit beeper GTIA channel at say 4 or 8 DLIs per frame. At 400Hz, you can play bass up to 200Hz square wave, and/or do kick drums.

Similar to how GoatTracker/atarisid/RMT2LZSS could work together, you can also play a beeper tune on GTIA alongside. It's just a matter of assigning just enough CPU time to each. Imagine two softsynth channels, two 64kHz Pokey channels, and one or two beeper voices or a low sampled bass or kick drum channel on GTIA And SID (emulation) to LZSS could be written (save cycles in comparison to running the original C64 6502 player code which I do now), and something similar could be done with beeper/sequenced samples on the 1-bit GTIA channel. SID2LZSS could be nice for the C64 folks, too

How was this recorded? This sounds worse than I remember how an original SID (not emulation) sounds. Where are the higher frequencies? It sounds like AM radio. Everything above 8kHz is cut at least 6dB per octave 😕 I know C64/SID aficionados have trouble hearing anything above 10kHz, but even on SID this should sound way beter. The lead flute sounds like the player has a blanket over its head Edit: the ST remix you posted after this sounds way more open. It's like breath of fresh air compared to the SID version. It's how a dog feels if his leach is finally removed and he can finally run free in the park

Don't know which browser you use, but you probably have a location bar/field. That's the link. If you select the whole string, CTRL-C, and CTRL-V where you want to paste it. For example, this is a link to this current thread https://atariage.com/forums/topic/316719-video-garbage-on-just-obtained-1200xl/page/1 . I clicked display as link. If I don't do that, it becomes this:

Just go to the thread, copy the link location, and paste it here. Currently the forum software even creates some sort of sub-window, showing partially the first post, and means to go to that thread, either in the current tab or a new one.

The downside of using a SID emulator (like atarisid) is that it uses 90-95% CPU time, approaching 100% at peak times. Not much left for a display, let alone a game. You can just use GoatTracker, and after conversion to atarisid, you can replay it with whatever waveforms you can define in 256 bytes of data. Currently, atarisid 6.1 uses channel one for the 15.6kHz timer, and the other three channels to replay either samples, or noise. The latter is done by a native Pokey noise generator. If you can assure the first SID voice never uses noise, you can get away with three pokey channels. Channel one will serve both the timer interrupt and a volume only channel. CPU cost will be the same though. Now cut out SID voice 3, and it'll take only two pokey channels and perhaps 25% less CPU time. Then can you play a modified RMT2LZSS on Pokey channel 3 and 4 and have a decent title screen, for example. Not a game though. I have mentioned these ideas several times on AA, but nobody has ever picked up the glove, so to speak Me neither, although I did some experiments with different waveforms. I call it atarisid and/or SID emulation, but underneath it's just a generic softsynth.

SID has only three channels. The 2A03 has five channels. Two PWM, one triangle, one noise and one (low replay rate) sample channel. The above cybernoid drums are samples. And the 2A03 sounds a lot more brighter to begin with

Do you still have an Atari computer? Do you have a diskdrive? (1050 or otherwise) I backuped all my disks with an 800XL, MyIde1, and a real 1050. But, for example, if you don't have a computer, but you do have a diskdrive, something like this could be helpful. Works with Mac and Linux, too, apparently. I have no experience with this product. If you don't have any Atari equipment anymore, a Kryoflix with matching drive might be an option, too. Not sure how the Mac support is on that one.

Could you check if Pokey Explorer runs on a real hardware with 16kB of RAM? I specifically designed this last year to be compatible with a non-upgraded 600XL, but was never able to check it on real hardware.

This probably won't work every time. Especially if more variables are added. There's no guarantee that DLIST$ and STAT$ are properly aligned (1kB and 4kB alignment). A possible solution would be to overwrite the first three $70/112/'p' of the OS generated display list with a jump to page 6. Do your status bar there, including its screen memory, and jump back to the original display list.

I'm a VHDL/Verilog n00b, but it would be nice if the PBI ROM of say 128kB (64 banks) would be split in two or more PBI devices. But if not, the first PBI ROM bank could install several drivers that all dispatch through the first bank, and select the bank they need for further processing. Very true. The same way you do inter-bank JSRs and return would be needed between the main OS bank and the "other" banks(s). Bigger window size is always welcome, but it's indeed questionable if timing critical routines need more than 2kB Edit: either way, it would be completely in the spirit of the original OS. No OS changes are necessary. And considering that most drivers probably need more than 2kB anyway, a dispatch bank would not significantly increase the execution time.

Nice improvements! This is not half a second. $30 is 48

👍 Yes, maybe it's a better idea to increase the PBI ROM space significantly instead of leaving the OS ROM bank switch register unlocked. Although an option to have that ability could still be nice, because with a 2kB PBI ROM window, you might have to split up drivers to fit in several banks, which is not needed if you can temporarily switch in ~10kB of new ROM code. I'd say implement both options

But that doesn't mean we can't have this. It's just that candle says he won't provide it. Anybody else is free to design their own. The last few days I'm in the mood of posting ideas that others might pick up for a new project, or that lead to other ideas and/or solutions. The "problem" is that for some people this is already way too much. Even opening up the computer is challenging for some, let alone remove the shielding when its not screwed to the board. Then, either remove the RAM chips (hopefully socketed, if not...), or remove the resistors going to the RAM chips. But which resistors? And just cut them, leaving the pins in place? Most non-technical people have already stopped here. Then you need to lift a 40-pin chip without breaking its pins, assuming it was already socketed (or desolder, place socket, etc...), And finally one or two more wires to solder. That's not really drop-in IMHO. A 1064 (clone). That's drop-in. Or plug-in, in this case

Sizecoding is the opposite of sex. You want to reach the result as fast as possible, with the smallest size

I wonder how hard it would be to make a 1064 replica with SRAM. I'd say, edge connector, small PCB with 64kB SRAM and minimal logic, pass through edge. Cost at quantity of 10+ probably less than $20 a piece. Note that this is an idea, and I'm not planning on making such a device

Take especially good care of cleaning and reseating the GTIA chip and its 4050 helper. That's where the video signal is generated.