ivop

This reminds me a little of Red Dwarf. Looks like this could be fun

I did run the first instance of atarisid on a real atari, but never the second and third (this) version. Today is the first day I heard them coming from a real Atari myself I actually think they sound better than through emulation.

There's one on side B of Mega Magazine #3, including source code. Please keep in mind that I was a kid when I wrote all that, including the article on side A.

Or a wiznet 5100. I have one hooked up here for well over a year, but did not get around to actually do something with it. Also, I'd rather want it in a cart instead of hanging at the joystick port and bitbang SPI to it.

Do not forget that the amount of data to be processed has also increased enormously. A single cycle faster per pixel faster in assembly can mean the difference between being able to play a H264 encoded video on your hardware or not being able to. Look at FFmpeg (a cross-platform multimedia project), there's still a lot of assembly code in there for the speed criticical stuff. Also, for a long while, most compilers did not take any advantage of SIMD instructions. As for 8-bit c-compilers, IMHO the biggest mistake is to switch to a "simulated" stack. Just use the CPU's stack for return addresses, make function variables static (i.e. fixed memory addresses, not on the stack) and forget about recursion. Most of the time, you don't need it, and if you do, program around the compiler's limitation. The resulting code will be way faster than sdcc, cc65, etc...

Seconded. Your avatar btw. shows how simple graphics can be sometimes, and still highly effective. With only a few pixels it is obvious that the guy dressed in black is way older than the other one

Here are some pictures of Amsterdam. 24M evals 13M evals 20M evals All with laoo palette and chess dithering and /s 1 I have a pretty slow computer, so perhaps somebody could run a couple of hundred million evaluations with better settings

Here's a patch with some fixes for Linux and g++ (warnings, deprecated stuff, etc...) and an updated Makefile. One can now do a normal build (make), a profile generate build (make pg) and after running the rastaconv-pg binary for a while, one can make a profile-use build (make pu). The resulting rastaconv-pu binary should be faster ivop.patch.zip

I don't have a Mac running Mac OS X at the moment, but it should be possible to get this to work with MacPorts and the Qt libraries. Perhaps you can get one of the Aspeqt devs to (cross)-compile a (static?) binary or work together to get the problems you experience resolved?

Yeah, tape takes ages. But I have fond memories of waiting 15 minutes for Boulder Dash to load from tape, fail once, reload and after about 35 minutes we had the game running. And this was a special day, mostly sundays, on which we took the Atari downstairs to our colour TV (on week days, my brother and I played games in black and white on our old TV upstairs). If you really want to relive the old days, press play on tape edit: oh, and Boulder Dash was worth the wait and still is

I'm interested in a second run, too. BTW any words on what throughput you can get with the current drivers and stack?

Here's a schematic (original by Nick Kennedy) and pcb I did a while ago. I etched it myself with a mixture of hydrochloric acid and hydrogen peroxide. This was also a test board to see how well it would etch. The schematic is simple enough to build on a protoboard though. http://www.atariage....089-sio2pc-pcb/

I just cross-compiled these from within Debian Linux (wheezy) and instead of only sharing them with the person I did this for, I thought I might just as well share them with everybody. Source code (GPL) is included. The win32 binary has been tested to work with wine under Linux. I cannot test the win64 binary, but it should work as well. Note that this is a command line utility. siddasm2.exe input.sid > output.asm. The output is in atasm format. It takes NSF (NES) and SAP (Atari 8-bit) files as well. Sid files need to be PSID. RSID is not yet supported. Edit [2015-07-17]: Updated to v2.2, hopefully fixed /dev/null issue on windows. Edit2: added source code. siddasm2-2.1-win.zip siddasm2-2.2-win.zip siddasm2-2.2-src.zip

Could it be that you forgot to push some changes? A lot of cfg variables are not declared.

I think the fastest is still to use a 512-byte look-up table, if you can sacrifice the memory. ldx 128 ; 3 lda lsbtab,x ; 4, tables must be page-aligned sta 129 ; 3 lda msbtab,x ; 4 sta 130 ; 3 ; += 17 If, as you say, bit 7 of the value in 128 is for other use and should not be part of the calculation, you do not even need to mask it out before using it as an index. Just ignore it when calculating the tables. If you do mask it out before you use it as an index (lda 128, and #127, tax) you can reduce the tables to 128 bytes each.

Thanks. I see it's a buffer for the address lines. BTW one could probably use a 173, too, which is a quad D-type latch with tri-state outputs and hence has a lower pin count.

What is this LS573 fix you speak of? I cannot find anything about it through google.

Recently I have been "collecting" all the different ways to generate pulse, sawtooth and triangle waves with the pokey chip, and while doing that, I thought of a new way to approximate a sawtooth wave. Well, I think it's a new way because I did not read about it somewhere else, but I'm not sure. It works like this: play frequency divider F on channel a, distortion 10 play frequency divider F/2 on channel b, distortion 10, half volume F/2 must be an integer, so F&1 == 0 (i.e. only even numbers for F) AUDFx are loaded with F-1 and (F/2)-1 after setting AUDFx's, restart the polycounters by writing to STIMER This results is one channel playing exactly double the frequency of the other and both are almost exactly in-phase. The result is as follows: a: 001100110011 b: 010101010101 r: 012301230123 To the ear, this sounds a lot like a sawtooth wave. Basically, both waves add up if they're in sync. There is no decrease in volume as is the case with interfering 1.79MHz based waves resulting in a sawtooth.

Thanks. I'll make sure I'll check that site, too, next time!

Recently, in another thread, somebody asked if the RMT format was open and described somewhere. Nobody answered that question. I have googled extensively, but alas, I did not find the page you mention. Well, I had fun RE-ing it and writing an rmtdump utility

Judging by the number of downloads, there's either no interest or it was not such a good idea to post it on my blog only I reverse engineered the file format used by Raster's Music Tracker. By Stephen's suggestion, here's a link to my blog entry. http://www.atariage.com/forums/blog/293/entry-9243-rmt-file-format/ This might make it easier to write converters, instrument editors and/or an open source tracker

I've spent some time reverse-engineering the file format used by Raster's Music Tracker. Included in the zip-file is rmtdump.c, a utility that came to be gradually, while exploring the format. There's also rmtformat.txt that describes the format in pseudo-assembly. rmtformat.zip

Although not commonly used, my shasm65 assembler explicitely uses different mnemonics for absolute and zero page addressing. # absolute: lda 1 inc 1 # zero page: lda.z 1 inc.z 1 # immediate lda. 1

A sic! cart uses DIP. Don't know if they can still be bought, but they are fairly effective as a cheap flash programmer.

Which OS are you running? I am developing this all under Linux, but it should work with Cygwin or MSYS on Windows too. Here's a short description of what I do. As an example, I am converting "What Have I Done..." by Reyn Oudehand. First, I relocate the tune to $8000. This is not always needed (a lot of Hubbard tunes are already high enough), but I'll do it anyway, as it relocates the zero page locations, too. $ sidreloc -p 80 -z d0-ef -r 10-1f What_Have_I_Done_To.sid what.sid What Have I Done To..., Reyn Ouwehand, 1990 Reyn Ouwehand, $1000-$1e5d, 1 subtunes Relocating from $1000-$1fff to $8000-$8fff Analysing subtune 1 Verifying relocated subtune 1 Bad pitches: 0, 0% Bad pulse widths: 0, 0% Relocation successful. The I disassemble the sid so I can change access to the sid hardware registers to $1000. $ siddasm2 what.sid >what.dis Remove the equates at the top and replace by: SIDV1FREQLO = $1000 SIDV1FREQHI = SIDV1FREQLO + $01 SIDV1PWLO = SIDV1FREQLO + $02 SIDV1PWHI = SIDV1FREQLO + $03 SIDV1CTRL = SIDV1FREQLO + $04 SIDV1AD = SIDV1FREQLO + $05 SIDV1SR = SIDV1FREQLO + $06 SIDV2FREQLO = SIDV1FREQLO + $07 SIDV2FREQHI = SIDV1FREQLO + $08 SIDV2PWLO = SIDV1FREQLO + $09 SIDV2PWHI = SIDV1FREQLO + $0a SIDV2CTRL = SIDV1FREQLO + $0b SIDV2AD = SIDV1FREQLO + $0c SIDV2SR = SIDV1FREQLO + $0d SIDV3FREQLO = SIDV1FREQLO + $0e SIDV3FREQHI = SIDV1FREQLO + $0f SIDV3PWLO = SIDV1FREQLO + $10 SIDV3PWHI = SIDV1FREQLO + $11 SIDV3CTRL = SIDV1FREQLO + $12 SIDV3AD = SIDV1FREQLO + $13 SIDV3SR = SIDV1FREQLO + $14 SIDFCLO = SIDV1FREQLO + $15 SIDFCHI = SIDV1FREQLO + $16 SIDRESFILT = SIDV1FREQLO + $17 SIDMODEVOL = SIDV1FREQLO + $18 SIDPOTX = SIDV1FREQLO + $19 SIDPOTY = SIDV1FREQLO + $1a SIDOSC3 = SIDV1FREQLO + $1b SIDENV3 = SIDV1FREQLO + $1c siddasm2 sometimes incorrectly disassembles data blocks. Look for 'ill' and remove the line up to the ';' comment marker. There are .byte statements at the end of each line. Try assembling $ atasm -r what.dis ATasm 1.06 beta (A mostly Mac65 compatible 6502 cross-assembler) Pass 1: Success. (0 warnings) Pass 2: .......... In what.dis, line 46-- Error: Unknown symbol 'L_1118' sidreloc only relocates code that is actually run. Depending on the song, not every codepath through the player is actually used, so there can be unknown symbols. Replace them by the hexadecimal equivalent (i.e. L_1118 ---> $1118). I use this rudimentary script to fix all at once. #! /bin/sh A=1 while test "$A" = "1"; do B=`atasm -r "$1" 2>&1 | grep "Error: Unknown symbol" | cut -d"'" -f2` if test -z "$B" ; then A=0 continue fi C=`echo "$B" | cut -d_ -f2` echo $B $C sed "s/$B/\$$C/g" <"$1" >"$1".tmp mv "$1".tmp "$1" done final assembly pass: ATasm 1.06 beta (A mostly Mac65 compatible 6502 cross-assembler) Pass 1: Success. (0 warnings) Pass 2: Success. (0 warnings) Assembly successful Compiled 3678 bytes (~3k) Writing raw binary image: 8000-8e5d Compiled to binary file 'what.bin' Now move what.bin to your sid2gumby directory. Edit sid2gumby.sh65 and add a section 'what)' to the case statement at the top. Check the disassembly for the addresses of the init and play routines (0x8000 and 0x8003). Possibly remap the channels to your liking. what) .screen " What Have I Done To Deserve This " .screen " by Reyn Ouwehand " .screen " (C) 1990 Reyn Ouwehand " .org 0x8000 player_init=0x8000 player_play=0x8003 .binary what.bin CH_LEFT=2 ; CH_MID=1 ; CH_RIGHT=3 MID_HALF_VOLUME=0 ;; assemble the new sid2gumby binary $ SONG=what ./shasm65.sh -v -osid2gumby-what.xex sid2gumby.sh65 pass 1: assembled block: 7800 - 79ef (01f0) assembled block: 8000 - 8e5d (0e5e) assembled block: 2000 - 7594 (5595) assembled block: 02e0 - 02e1 (0002) pass 2: assembled block: 7800 - 79ef (01f0) save block: 7800 - 79ef (01f0) assembled block: 8000 - 8e5d (0e5e) save block: 8000 - 8e5d (0e5e) assembled block: 2000 - 7594 (5595) save block: 2000 - 7594 (5595) assembled block: 02e0 - 02e1 (0002) save block: 02e0 - 02e1 (0002) done run: atari800 -nobasic -windowed -showspeed -pal -audio16 sid2gumby-what.xex People not wanting to roll their own, but just want to listen to the tune, sid2gumby-what.xex is included in the zip-file. reyn.zip