Line by line from SD interpreter
jaeg
Posts: 156
Ok so I have an idea and wanted some feedback on it.
I was thinking about having the Propeller interpret commands from a text file on a SD card as it going through the program it will only add the variables it encounters to RAM. I doubt this would save room programming wise but it would make it easier to save programs on a retro-style computer so you can program it on the fly without assistance from another computer.
Does this sound feasible. It's more of a fun project than a practical one I know but the idea sounds neat to me.
I was thinking about having the Propeller interpret commands from a text file on a SD card as it going through the program it will only add the variables it encounters to RAM. I doubt this would save room programming wise but it would make it easier to save programs on a retro-style computer so you can program it on the fly without assistance from another computer.
Does this sound feasible. It's more of a fun project than a practical one I know but the idea sounds neat to me.
Comments
I know GOTO tends to be bad programming etiquette and I'm not one to burp at the dinner table so I might give a go at functions which should be easy enough to implement. I'm new to the propeller but not completely new to programming.
Offtopic - Is it possible to access graphics from an SD card only when they are needed and past them on the screen then remove them from the ram? I'm seeing some examples game wise of what people have done and wondering how they fit that into 32k.
Yes, that is exactly how I am writing a program at the moment. I have a huge program that I am using in many different ways depending on data in a tiny text file. In software I have objects that take data from a buffer array (256 bytes) and process them and then hand over to the next object. Eg, a simple example might be a keyboard object that creates data, an object that looks for all instances of carriage return and adds a line feed, and then a vga display object. Each object has a number, so the above might be written as 8.22.9
Ok, it is a bit of an esoteric language I've got there, but the beauty of that is that I can change those connections with a text editor on the propeller. So I might plug in other objects, like one that takes raw data and turns it into packets with a checksum for radio transmission. Then another object that decodes those packets. I've also got an object that prints to an LCD display, so in the example above, I change 8.22.9 to 8.22.10 and it now prints to the LCD.
I'm finding this concept very convenient for changes out in the field.
Then you could extend the concept with conditional statements - similar to batch processing in DOS.
It is quite an interesting way of coding to abstract 100 lines of a packet decoder into one number.
The board I'm getting is the Propeller Platform SD from Gadget Gangster. I also got the touch screen module and computer input/output module too. I'm going to play with these a bunch till I understand SPIN better and possibly make a simplified version of the interpreter. The touch screen is for a virtual pet type thing I want to try to make. Not to mention anything else I think of. I like touch screens haha Guilty pleasure.
I think that when it comes to eventually using a multi prop design I'll design my own rather than get a new board. But baby steps first.
Running CPM would be pretty fitting since I'm going to be using an old Commador 64 case and keyboard. Me and my dad bought two last year from the same guy. One of them had water damage and didn't work but the price was still a good deal. I was thinking of using a prop to run the 8x8 matrix the keyboard uses and generate video/audio then have another one do RAM and another one be the main processor. I've actually started painting the case today. It was all stained up and tainted so I figured I'd give it a makeover and a new logo.
Now I'm just rambling... 20 years old and already rambling. Haha
Be sure and put some diodes in line with 8 of the lines as it's possible
to short-circuit that matrix by pressing more than one key.
I did this project myself a few years ago. If I can lay my hands
on the excel sheet I did when I mapped the 64 keyboard it might
save some time. I'll see if I still have it.
OBC
Come in Heater...
Ok, what are the specs:
Introduced: January 1982
Released: September 1982
How many: ~17 million
Price: US $595.
CPU: MOS 6510, 1MHz
Sound: SID 6581, 3 channels of sound
RAM: 64K
Display: 25 X 40 text
320 X 200, 16 colors max
Ports: TV, RGB & composite video
2 joysticks, cartridge port
serial peripheral port
Peripherals: cassette recorder
printer, modem
external 170K floppy drive
OS: ROM BASIC
Graphics first. Yes, I think we can do 320x200 with 16 colors and TV or VGA.
25x40 text - yes I think there is an obex for that.
Sound - hmm - there is the AY sound object - so sound is possible but might need some more coding.
Serial - yes.
Joysticks - might need to look at the specs for those.
Cartridge port - that might be tricky. But I think all the cartridges have been ported to the PC for use in emulators, so those files could be placed on a SD card.
Printer - not sure about the specs on that, but I have a board with a parallel port so it isn't that hard to change if needed.
64k of ram. You could do that with external memory.
MOS 6510 http://www.oxyron.de/html/opcodes02.html Hmm - not too much different to 8080 or Z80. Heater is our resident expert here.
As for hardware - the way we did CPM was to start with an emulation using limited memory in one prop (heater), add external ram (cluso's triblade three prop board), squash it all into one prop chip (me), then make it all run much faster by converting spin to pasm (pullmoll).
Cluso's triblade might be a platform to start with.
Yikes - I just checked the files in the CPM emulation and the 6502 is already done. See attached. Hmm - maybe it is just a matter of gluing all the code together?
Me? I'm a bit busy:)
Are your forgetting there is already a SID chip emulation SIDCog, see here: http://forums.parallax.com/showthread.php?t=118285&highlight=6581
You will need some hardware to run all this on, Bill Henning is just about to release the Propcade board. Designed to do exactly what you want:http://forums.parallax.com/showthread.php?t=121315
It has support for joysticks, stereo sound, memory expansion etc.
The 6502 processor emulation is done already as you say.
Me, I'm going to make the ZiCog Z80 emulation run using PropCades SPI RAM expansion so it will run CP/M.
I still have the C64 original board. It's only one side that was damaged so I'm guessing the RAM, processor, SID and CIA chips still work. The ram would be difficult to interface with since it's 8 8k chips all linked together to a....a... I can't remember the IC name. I think they are grouped in sections of 4 connected to the other IC then those two IC feed into the processor. I could be wrong though.
I've seen lots of projects and a website dedicated to SID ic so that would be hard to interface with.
Chances are using these IC would be more difficult than just having the Prop chips doing it by themselves though. Haha
What do you guys/gals think of an Atari emulator?
320x200x4bpp = 32,000 bytes
32,000 bytes x 60fps = 1920000 bytes per sec, ie ~2MB/sec just for display refresh
- Morpheus could do it
- TriBlade could do it if someone write the right video drivers
- FlexMem can do it once I have the 2 cog 6MB/sec driver running
PropCade can *almost* do it - the problem is the 16 color 320x200 bitmapped mode, which needs approx. 2MB/sec for screen refresh.
I actually think I could get 2MB/sec out of the SPI ram's on PropCade with a two-cog driver, however that would only allow updating the screen during Hsync and Vblank.
PropCade could do a VIC20 easily though...
Morpheus could easily handle a C64
The C64 had 16 colors only, but was able to display all of them on the 320 pixel screen. The mixed display mode, for multi-color, vs two color cells is the most difficult part for the Propeller, along with sprites, which I think are easy for the Propeller. (C64 style sprites are more than doable on the prop)
IMHO, one trouble spot for an Atari emulator is the complex interaction between POKEY, GTIA and ANTIC. Lots of stuff there to deal with, and a lot of code used it.
The Vic is something I want to try in the near future. IMHO, a Vic would be sweet on the Prop.
(as would Apple 8 bit computers, assuming we can get usable virtual memory a 48K machine is really needed for the core Apple experience)
VMCOG now provides a reliable 64KB VM, and I've started work on the next version of VMCOG which will support up to 2MB initially, later to be expanded to a 256MB VM.