CYGN-B

[lasermaster1977]

Yes, it was XY 8-bit DAC outputs. I'm not sure exactly how the system controlled the DOGN board. I see in the 351 data frame that there is a 1 byte speed value and a selector bit or two. Here is a re-post from page 18 of the sin table:

$1CD0:
00000000000101010202020303040404050506070808090A0B 0C0D0E0F1011121314151617191A1B1C1E1F20222325262729 2A2C2D2F3032333537383A3B3D3E404143454648494B4C4E4F 5152545557585A5B5D5E5F61626365666768696B6C6D6E6F70 71727374757576777879797A7A7B7C7C7C7D7D7E7E7E7E7F7F 7F7F7F

That is 128 bytes for a quarter cycle. Nothing came from the CYGN-B. The 4 byte presets (16 of them total) came from on board ROM. I think the presets represent two 16 bit values that serve as frequencies for two software oscillators that use the above lookup table.

Tiny means the sin table and all the machine language routines including a random numbers generator, several motion path generators, a bank of fixed offsets, the dogloid presets, various house keeping code, and the cycloid generator all within less than 2K.

Thanks Greg, very helpful info. Will get back to you. So is the .op file you posted possibly the ROM code? It is exactly 2K Bytes long. I remember having the machine code listed on a monitor screen. I do now see the 128 bytes of the quarter cycle within the 2K.

[Greg]

Thanks Greg, very helpful info. Will get back to you. So is the .op file you posted possibly the ROM code? It is exactly 2K Bytes long. I remember having the machine code listed on a monitor screen. I do now see the 128 bytes of the quarter cycle within the 2K.

Yes to all, except I didn't post the .op file, I emailed you it, and I had spoken to Jon and obtained permission to give specifically that specifically to you.

That .op file is produced by a Fast Assembler file that is edited and compiled on a c64, and is fully commented, labeled, etc.

Note there is code in there I wrote that is reading the paddles and using the values to vary the speed (was a 555 on board the original device) and the parameters to the cycloid generator.

[Greg]

ekeefe: email sent.

ekeefe: Oh, I just realized you were talking to laserist about the 6502 circuit. I'm not sure if you mean the re-design of the CYGN-B which was mentioned, and which is not a 6502 circuit, or a board that can run the 6502 code from the DOGN with 4 XY channels, buffered outputs, etc.

[lasermaster1977]

Yes to all, except I didn't post the .op file, I emailed you it, and I had spoken to Jon and obtained permission to give specifically that specifically to you.

That .op file is produced by a Fast Assembler file that is edited and compiled on a c64, and is fully commented, labeled, etc.

Note there is code in there I wrote that is reading the paddles and using the values to vary the speed (was a 555 on board the original device) and the parameters to the cycloid generator.

Thanks for jogging my ol' fart memory. Right, I remember now, but I couldn't recall that earlier, getting old does that to me, sorry.

After I got the .op file by email from you, I looked at it, saw some weirdness about it, an had intended to enter it into my S-C Assembler to better document it. I hadn't done that as yet. Today, I quickly loaded the .op file into Notepad++ and viewed it with a Hex plugin. Anyway, I'll put some focused time into it because of my 6502 affinity.

The 2K of code had to hardware mapped into the top 2K of the 6502's 64KB of potential memory space, since the Reset pin causes the processor to load the contents of memory locations $FFFC (low byte) and $FFFD (high-byte) into the program counter. Now there are lots of ways to "trick" this to happen but I notice what is in the .op is not a full 2K of bytes. Those 2 memory bytes normally point to a 16-bit address where ROM/RAM program execution starts.

But, that's not what I see in the .op's upper memory locations. I'll PM you with more specifics, a bit later.

[Greg]

lasermaster1977: I can tell you everything about that file, so don't waste your time puzzling things out, just please ask. I put a lot of work into that and I'm happy to discuss it. Give me until next weekend to set up the c64 again and I'll see what can be done with the source file. I think you are barking up the wrong tree for the entrance vector. I need to see the code again, and I'll be able to quickly tell you how it makes sense.

[lasermaster1977]

lasermaster1977: I can tell you everything about that file, so don't waste your time puzzling things out, just please ask. I put a lot of work into that and I'm happy to discuss it. Give me until next weekend to set up the c64 again and I'll see what can be done with the source file. I think you are barking up the wrong tree for the entrance vector. I need to see the code again, and I'll be able to quickly tell you how it makes sense.

Sounds great, but as I said there are lots of ways to "trick" the program counter's "RESET" first 16-bit address to "look" like it starts at FFFC and FFFD.

[laserist]

I should mention it was a 6502 family processor, but as I recall a smaller address space.

[lasermaster1977]

I should mention it was a 6502 family processor, but as I recall a smaller address space.

Thanks for that insight!

That makes a big difference in trying to understand the DOGN implementation. The 6503 through the 6507 and reduced memory addressing capability...only 4K. Sound familiar?

I should add the '04 and '07 had 8K addressing space. But the '03 thru '07 where 28 pin packages, so these only had 12-bit address buses.

[laserist]

Snip

@laserist
I'm happy to help with a redesign of the 6502 circuit. I work with a bunch of different microprocessor chips, including: Intel 8051, PIC, AVR, Propeller and ARM. So getting something more modern working wouldn't be too much work. I love updating old tech.

Snip
ED

Thanks, but the 6502 and especially the Dogloids was one of Greg's things.

I would like to do a 3U euro card format that did:
Multiplex 16 x/y image selection
Master x&y gain
Individual x&y gain
Variable rotation
Fixed rotation
Audio mod multipliers with some switching
Spiral multipliers with some switching
A place to insert offset
A place to insert spiral sweep
A place to insert a different kind of spiral sweep

It would be one channel per card. I think that Laserium missed abstracting that some things are image processing and some things are images. Now I realize you can draw the abstract line in the sand wherever you like, but when you're doing a live show knowing where to reach for the thing you want to do - matters.

Thanks, let me know if my musings intrigue.

[Greg]

I would like to do a 3U euro card format that did:
Multiplex 16 x/y image selection
Master x&y gain
Individual x&y gain
Variable rotation
Fixed rotation
Audio mod multipliers with some switching
Spiral multipliers with some switching
A place to insert offset
A place to insert spiral sweep
A place to insert a different kind of spiral sweep

It would be one channel per card. I think that Laserium missed abstracting that some things are image processing and some things are images. Now I realize you can draw the abstract line in the sand wherever you like, but when you're doing a live show knowing where to reach for the thing you want to do - matters.

Well that raised the bar.


I remember seeing at a Science Museum in Ottawa in the 1970s's a leaking cup of sand swinging on a string that drew the abstract line in the sand. According to a museum staff person, I was the only kid they had seen study the instructions first.


Yes, the one channel per card thing and all the rest. Excellent piece of thinking there. I'm all for it. I probably can't help with the hardware, possibly with the software. I can offer to discuss and track details.


Suggested starting points: Can this be viewed as a bunch of analog and digital reads, a processor, and a bunch of analog and digital outs, with user loadable software and configuration info for the image processing part? What other considerations are there regarding inter-board and / or board / controller communications?