AtariAge Forums: AtariAge Forums -> EricBall's Tech Projects

I've finally finished (and debugged) my Fast Discrete Hartley Transform for the Propeller. It takes 2^N signed 32 bit input samples and produces the output in the same array. I've measured the following:
16 samples in 12,496 clock cycles
64 samples in 87,648 clock cycles
256 samples in 534,656 clock cycles
1024 samples in 2,899,504 clock cycles
4096 samples in 14,668,112 clock cycles

At 80MHz that's 27.5 1024 sample DHTs per second!

Most developers understand it is possible to trade off space for speed, e.g. unrolling loops or using table lookups instead of complex calculations. This is particularly true for low level programming where you are often trying to squeeze out the maximum speed in the minimum space. But I've recently discovered Propeller Assembly (PASM) it's possible to maximize speed and minimize space simultaneously.The Propeller is different from most processors in there are no dedicated ALU registers. Instead, any 32 bit entry in processor RAM may be used as a register. Thus processor RAM can be looked at as a 512 entry register file. Or 496 instructions (16 of the registers are dedicated to I/O), with each instruction taking a single register. Or 496 32 bit data values. It is even possible (and sometimes necessary) to modify an instruction using ALU operations.In the program I'm working on, I've programmed two 16.16 x 0.16 fixed point multiplies; multiplying one value twice...

Why is it people think that because the 2600 is "simple" (at least in terms of what level of graphics it can produce) that it will be easy to emulate?

The reason it isn't is because the 6507 and the TIA are "tightly coupled" - each can do things which have an immediate impact on the other. The 7800 and NES are loosely coupled unless interrupts are used. But In the 2600 the 6507 & TIA could almost be regarded as a single entity.

Anyway, occasionally people suggest creating a 2600 emulator for the Propeller. In their mind they assign a cog (processor) to each function - CPU, graphics, sound, input, etc. I typically scoff at them, citing the difficulty in emulating the 2600 - if for no other reason than the clock relationship between the 6507 and the TIA.

But earlier this week I started thinking - why not give it a shot. Put together a 6502 emulator with an eye to making it usable in a 2600 project. It might be fast enough or feature complete enough,...

So I posted my OnePinTVText driver. That's right, a text display on a TV using only 1 pin. Actually, there's no reason it can't do any other monochrome display with an 8x8 font. Anyone for a nice game of chess? Not much feedback yet. Sniff. I'd like to try to get it to work with the internal RC ~12MHz clock, but my first try didn't work. So I'll put that idea on the back burner for the moment.

My next project is to add SD support to my Z-machine interpretter so it can play the Infocom games. The first step is to wire up an SD socket. Unfortunately, no-one makes a pre-built adapter that I can just plug into my Demoboard. (There's one which is usable, but it still requires jumper wires.) So I started with a old 5.25 floppy edge connector (which apparently works). Unfortunately, the wires in the ribbon cable aren't stiff enough to push into the breadboard. So I've wirewrapped them to some wirewrap pins I have. I don't have any jumper...

 z3c.zip (41.63K)
Number of downloads: 62
It works! I found the bug in the parsing routine (dumb error on my part). I'm going to call this chapter complete.

The next chapter is to create z3.spin based on this code. I/O will probably be based on a serial terminal interface. And it will run catseye.z3, which is small enough to fit in HUB RAM (hopefully), so no SD I/O. The objective is to do as little as possible other than porting the code from C to SPIN.

Z3.C is functional, but I'm still bug hunting. It now gets to the first input in HitchHiker's, but doesn't grok the input. MiniZork starts, but misfires printing out the detailed location info. (Which probably means a bug is in the object/property/attribute code somewhere.)

What I really want is a PC trace from a known good interpretter, which I could then use to narrow down my bug hunt. Unfortunately, none of the Z-Machine interpretters I've found has this option. I could look at their source code, but I'm not sure that would be any easier. It would be one thing to look at something specific (like how to handle Jump if Equal with more than 2 operands), but working through every opcode would be much harder.

But I think I'm close. One idea I had last night is to compare what opcodes HitchHiker's and MiniZork use before the first input. Anything which isn't used can't be the problem.

What do you think the following C should do?

unsigned byte zmem[128*1024];int read_word( int a, x ){  a = zmem[a++]<<8 + zmem[a];...}

There are three (!) errors in the above code:

• precedence error : addition is done before shift
  
• order of operations : is a incremented before the second array reference?
  
• compiler bug : a contains a++ after the operation

All three can be worked around by using a temporary variable. Here's another gotcha I ran into:

int PC;void run( void ){...  op2code( op & 31, zmem[PC++], zmem[PC++] );...}

Looks reasonable, provide the next two bytes in the instruction stream as operands. Again, there are several potential bugs lurking:

• is PC incremented before or after the function call (tested - it's before, at least with my compiler)
  
• order of operations : which operand gets which byte?
  
• is actually PC incremented before the second array reference?

#3 turned...

Zork! HitchHikers! Ahh, the memories of glowing green text and the frustration a text adventure can bring.

Interestingly, Infocom had the forsight to create their games as a program for a virtual computer. That way they didn't have to create separate versions of each for each home computer. The same game file could run on multiple home computers using the existing interpretters. And when a new home computer reached the market, the whole library of games would be available by just writing one interpretter.

My plan is to create a Z3 interpretter for the Propeller. (Although I'm skipping the features only used by two Z3 games.) No small feat given the Prop only has 32K of onboard RAM (plus 2K dedicated to each processor) while the Z3 story files can reach 128K. Obviously some kind of virtual memory will be required. The plan is to use standard SD cards to store the Z3 story files. When first started, the interpretter will copy the Z3 file to a SAV file and swap...

The Propeller projects I listed in a previous blog:

PWM based waveform generator
Done, but I'm not going to release it as the limitations outweigh the results. Since the waveform is hardcoded, there's no way to dynamically change volume. There's also no way to internally mix voices onto one channel. And, finally, the sound isn't that impressive. (I was hoping to get something which really sounded like a cello or trumpet.)

single pin NTSC text display driver
Functionally working 100% even without a filtering cap. Now I need to make the hardcoded variables into parameters and calculated values. I might even do a PAL version. Plan is to release this to ObEx.

IF_NEVER timing tests
Complete. All IF_NEVERs take 4 cycles, irrespective of the opcode. It would have been more interesting if it wasn't, but this result merely confirms the datasheet.

Extend NTSC240H to have background tiles too
On hold pending interest (mine and others).

I think my next...

Last night I posted my sprite video driver to the Prop forum, complete with demo (a bouncing beanie which explodes into individual sprites). Screen capture in MPEG2 of first 20 seconds:  ntsc240h.zip (6.28MB)
Number of downloads: 61

So far, I've had two comments - one attaboy & one not-very-useful. (The latter obviously can't see the videogame potential.) But like the circus bugs in "A Bug's Life" I crave applause. I want that feedback!

Sigh... other Prop projects I'm considering:

• PWM based waveform generator
  
• single pin NTSC text display driver
  
• IF_NEVER timing tests
  
• Extend NTSC240H to have background tiles too

I also have Leprechaun & SpaceWar! 7800 to finish. Getting back to these means relearning my own coding, a daunting task.

I also need to get the "new" PC for my Tempest cabinet working, and one of these days (maybe this summer when my Dad is in town) make some progress on my MAME cocktail cabinet. Oh, and how can I forget...