If you hand edit the ramSave.txt file and put in a value larger than a byte, the emulator (PC side) will allow it- and when a propeller requests the data, it even shows up in the emulator window (PC side) and then the software crashes (it can't deal with the extra bytes I assume)-
So just a caution, don't hand edit your ram file and put in values larger than 255 ~
Ryan
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Ryan Clarke
Parallax Tech Support
Yeah the VB will allow 0-32768 at present, but returns only a single byte char to the Propeller. VB cannot assign int to byte obviously.
This was developed as a test/stop gap to solve Goog's RAM issue. If there is interest I could easily develop this to deal with bytes, words and longs - even pages potentially. Also could add in some error handling to deal with serial comms issues.
I just think if we (all of us working on various projects, not just this one) spend time on Propeller objects, codes, etc, we should make them as modular as possible, in essence creating a great tool set-
Who knows what somebody could use this VB app for, but combined with a Propeller object, it could add a functionality that didn't exist before- and probably the best part about this type of development is when someone wants to do something similar, but not the same: having a working existing framework to go off of can be a huge help/time saver~
I like the way Jeff Martin put it the other day: "As objects grow, its like new commands are added to the Propeller all the time."
Ryan
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Ryan Clarke
Parallax Tech Support
1) Could you post the VB Source code once you get your kinks out (or sooner, if you desire). I will likely take that and do some less-specific things with it for reading C64 files.
2) Is there a way to do the communication over the existing USB port on the propeller demo board (rev. c)? I don't have a USB2SER device and I don't really want to make people get it just to get the C64 emulation working. Is it just a matter of setting it to pins 30/31?
Ya know, you just really simplified HD access... Really...
Same concept as your program, but only this one takes a file path \ name and starts returning bytes...
Or... send it a file path \ name, then start sending bytes...
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Just tossing my two bits worth into the bit bucket
Oh, and one more thing... the VB program only uses COM ports? Are you able to program via USB? I haven't done it, but I could probably do some research and update it to do that. That way, we can have USB-to-USB communication between the PC and the Prop. board.
If you look at the current demo board, it has an FTDI chip on it- in VB it is easy to grab the com port (virtual com port, via the FTDI chip)- It becomes a different task to do straight USB.
Ryan
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Ryan Clarke
Parallax Tech Support
Goog
As things stand right now, there's only two ways to connect a propeller to a PC...
USB2SER or SERIAL. In either case, the end result is SERIAL, which is a com port.
So, there's no worries or issues there.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Just tossing my two bits worth into the bit bucket
And yes, to simply use the USB port built into the board use the following:
PC_rx = 31
PC_tx = 30
Keep in mind while you have the C64 Ram window open on the PC, you should make sure the PORT is CLOSED when you are programming the Propeller, then after it is loaded, simply click the Port button to open it.
Ryan
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Ryan Clarke
Parallax Tech Support
this gave me an idea for a propeller object...
A wireless datalogger...
Imagin a single PC with a wireless reciever and hard drive space...
Propellers with datalogging sensors (or anything else for that matter) collecting data and sending it back to the PC via wireless reciever...
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Just tossing my two bits worth into the bit bucket
OK - i'll do some updates when Im back at home - specifically the following come to mind:
1) implement byte/word and long
2) implement some error handling on the propeller object (if you loose comms to PC)
3) improve the load and save
4) PC memory map display?
Coog - I thought this was a "stop-gap" filler to allow you test your code. Once you've proven your code, we/you were going to write a large ram object with several i2c ramton chips? (i.e. this is a temp solution?)
is that right? Or is this only if I don't use the demo board? Also, what wiring would I need? Specifically, which pins on the USB (30/31 on demo board) connect to which pins on the DB9 serial port on the PC? Did I get that right?
I think (Ryan will probably correct me if I am wrong) but the dev board has a USB2SER (FTDI chip) built it, and it takes a mini-USB cable. Then simply install the FTDI drivers on the PC and you'll get COMx (from the command prompt type "mode" and it'll show your com (and lpt) ports)
On the object give it the pins
PC_rx = 31
PC_tx = 30
and this will work.
Note that you need to "CLOSE" the port while you program then quickly "OPEN" the port afterwards before the waitcnt delay finnishes.
James said... Coog - I thought this was a "stop-gap" filler to allow you test your code. Once you've proven your code, we/you were going to write a large ram object with several i2c ramton chips? (i.e. this is a temp solution?) Yes, that is correct.· But at this point, I still have no communication with the PC... but getting closer.· I will order my RAMTRON chips today.
Coog - how about loading/storing programs on a MMC card? Yes, that would be great!
If you want to see the COM port you are on, you can either check through the Propeller tool: Run -> Identify hardware (F7) and it will show you where your Propeller is (ONLY if the port is open, i.e. not being used by the C64 app PC side)-
-or-
On a Windows box look in the ports list in your device manager-
You do not need the USB2SER, I used it simply to keep me from having to open and close the port (not really that big a deal)-
It is funny to think, a PC is simply a slave storage device to the Propeller in this setup [noparse]:)[/noparse]
I would think that this is a development step, and that the use of ICs would be the ultimate goal...
Ryan
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Ryan Clarke
Parallax Tech Support
I aggree with Ryan... It's a stepping stone...
As far as the MMC code, great! And, if I recall from the documentation, MMC and SD are identicale, arent they?
If not, then I'll just hop on out and get a MMC card... no biggie...
And Ryan, Yes, I'm laughin at the fact that in essence we are making the PC the slave to the propeller....
Woot! this is flyin!
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Just tossing my two bits worth into the bit bucket
WHEW! OK, I finally got my board to communicate with the VB program (after spending about an hour trying to figure out how to install the FTDI drivers. Little did I know that they were already installed when I first connected my propeller demo board. Duh. I just wish I figured that out sooner. Their install program crashed and I spent a while on this).
So now I can start testing my emulator code!!!
James, it would be much easier if I could use the VB source code - do you mind posting that?
Here is the first step in getting the emulator going.· You must have a RAM file (loaded with the C64 ROM files)·that the emulator will work with.· This C64 ROM Loader will use James' "C64 Ram!" program to store the large amount of data.
Once you load your ROM files into this RAM file/program, save it.· You will never have to run this program again after that, unless you delete or corrupt the file.
Sorry, I cannot post the ROM files - copyright laws say you have to have rights to the ROM data (which basically means you must own a Commodore 64).· You can find the ROM files on the Internet.· If you are really adventurous, you could pop the chips out of the C64, plug them into your Propeller breadboard·and download the data.· That might just be a fun project in itself, huh? [noparse]:)[/noparse]
Yeah I can post vb code - once i've got all the updates going. (not at home till tomorrow - so hopefully Sunday PM or Monday)
The SD and MMC are similar - the spec says you can use a MMC in an SD device but not the other way arround. I've only got MMC card code so best get MMC/RS (reduced size) if you want to use my Object.
The emulator seems to be working great so far, although I can't tell for sure until I can fiddle with the VB source code. I have it so that every time a byte is read or written to the bus, the LEDs on the board light up with the binary representation of the byte. The lights are blinking super fast, so it seems like things are working great. I will post my code as soon as I can get a debugger going on the PC side.
Here's something else that will be cool: I am going to use another COG for the VIC chip emulation - it is the chip that does all of the video work. I have it launched in a new COG right now and it monitors the bus activity and outputs the data to the TV terminal. Way cool!
The differences between MMC and SD is that the SD card is slightly thicker than the MMC card, and that it has some additional 'security' functions. (SD = Secure Digital)
Not that I've ever heard of anyone ever using those functions...
In all other aspects the cards are identical.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Don't visit my new website...
Well to top that off, The SID Mos6581 would fit nicely in a single COG as well. ^^
The only thing that would be hard to emulate in that sound chip would be the analog filter that was built in, but other then that it should be a walk in the park.
As advanced as the SID was for it's time, it's not all that complex.
Still composers made some really cool tunes for that thing and still do to this day.
Maybe I'll get out my old datasheet of the thing and write some firmware to emulate it on a COG. That is after I get done working on my current Sound Co-Processor design.
Well keep us all posted! This seems like a really cool project.
--Andrew Arsenault
P.S. I write my first programs and music on the C64 long ago. (lol) ^^
Well it just so happens that I will need some major assistance when it comes to emulating sound. I've always wondered how the PC emulators do it. The emulator I wrote on the PC doesn't have sound because I had no idea where to start, so if you think you might be able to help with that Andrew, I would appreciate it. Of course, we can work together on the overall structure... and I can definitely do some of the coding so you don't have to do it all. I do have a lot to do on the rest of the project as well.
Yeah, I wrote a lot of C64 when I was a young teen as well - in fact, the reason I am doing this emulator to begin with is so that I can understand all of those little things I never did being that young! What fun!!!
Sure count me in.
Sound programming is what I normally do anyway. (lol)
The SID shouldn't be that hard to emulate. Compared to some of the other Sound Co-processor/Generater designs I've wrote in the past and am currently working on, It's fairly simple and wouldn't be that hard to do.
Plus it'll be fun coding the Mos6581 in ASM anyway. ^^
I just can't wait until this thing says "PRESS PLAY ON TAPE" *grins*
This is version 1.1 of the bigMem object and c64RAM vb6 project.· Both are attached in ZIP format.
The following changes have been made:
1)· LONG variable support - tested with 10_000_000 + numbers
2)· Smaller and faster ramsave.txt files
3)· Timeout on readValue (changed from readByte) to allow program to continue in the event of comm failure(s)
(the compiled version of the vb6 app is in the ZIP file - for those without V-Studio 6 SP6)
I'm in the process of testing... The interaction between the Propeller and the PC Ram is great - it seems to be plenty fast for this testing phase.
I am having difficulty with some object interaction and object memory.· I need some answers on how objects relate to each other in SPIN.· I really need to have the ability to use "multiuse" or shared objects.· Any thoughts? (please answer in the thread below)··See my other post here:
Comments
Works well. I stripped out the LCD, and am using a TV object to run tests (this can be changed of course)-
I moved some of the pins used to make it friendly with the current Propeller Demo board:
Rx is pin 5
Tx is pin 6
Since I am using a USB2SER on a different port than the Propeller demo board, I don't have to keep shutting off the C64 Ram app-
The set up is:
TV connected to TV jack on Propeller demo board
USB2SER: Vss tied to Vss on Propeller demo board
Rx and Tx connected to pin 6 and pin 5 respectively
Demo runs great!
Ryan
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Ryan Clarke
Parallax Tech Support
RClarke@Parallax.com
Thanks for that - glad to know somebody else has it working. It was a bit too easy to develop if you know what I mean!
James
So just a caution, don't hand edit your ram file and put in values larger than 255 ~
Ryan
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Ryan Clarke
Parallax Tech Support
RClarke@Parallax.com
Yeah the VB will allow 0-32768 at present, but returns only a single byte char to the Propeller. VB cannot assign int to byte obviously.
This was developed as a test/stop gap to solve Goog's RAM issue. If there is interest I could easily develop this to deal with bytes, words and longs - even pages potentially. Also could add in some error handling to deal with serial comms issues.
James
Who knows what somebody could use this VB app for, but combined with a Propeller object, it could add a functionality that didn't exist before- and probably the best part about this type of development is when someone wants to do something similar, but not the same: having a working existing framework to go off of can be a huge help/time saver~
I like the way Jeff Martin put it the other day: "As objects grow, its like new commands are added to the Propeller all the time."
Ryan
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Ryan Clarke
Parallax Tech Support
RClarke@Parallax.com
Excellent! That was quick!
Two things, though...
1) Could you post the VB Source code once you get your kinks out (or sooner, if you desire). I will likely take that and do some less-specific things with it for reading C64 files.
2) Is there a way to do the communication over the existing USB port on the propeller demo board (rev. c)? I don't have a USB2SER device and I don't really want to make people get it just to get the C64 emulation working. Is it just a matter of setting it to pins 30/31?
Thanks - I'm anxious!
Goog
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Doing my part to keep the Commodore 64 alive!
http://www.commodorestuff.com
·
Same concept as your program, but only this one takes a file path \ name and starts returning bytes...
Or... send it a file path \ name, then start sending bytes...
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Just tossing my two bits worth into the bit bucket
KK
·
Thanks,
Goog
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Doing my part to keep the Commodore 64 alive!
http://www.commodorestuff.com
·
Ryan
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Ryan Clarke
Parallax Tech Support
RClarke@Parallax.com
As things stand right now, there's only two ways to connect a propeller to a PC...
USB2SER or SERIAL. In either case, the end result is SERIAL, which is a com port.
So, there's no worries or issues there.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Just tossing my two bits worth into the bit bucket
KK
·
Keep in mind while you have the C64 Ram window open on the PC, you should make sure the PORT is CLOSED when you are programming the Propeller, then after it is loaded, simply click the Port button to open it.
Ryan
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Ryan Clarke
Parallax Tech Support
RClarke@Parallax.com
A wireless datalogger...
Imagin a single PC with a wireless reciever and hard drive space...
Propellers with datalogging sensors (or anything else for that matter) collecting data and sending it back to the PC via wireless reciever...
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Just tossing my two bits worth into the bit bucket
KK
·
1) implement byte/word and long
2) implement some error handling on the propeller object (if you loose comms to PC)
3) improve the load and save
4) PC memory map display?
Coog - I thought this was a "stop-gap" filler to allow you test your code. Once you've proven your code, we/you were going to write a large ram object with several i2c ramton chips? (i.e. this is a temp solution?)
James
Coog - how about loading/storing programs on a MMC card?
So I need to get the USB2SER device? at: http://www.parallax.com/detail.asp?product_id=28024
is that right? Or is this only if I don't use the demo board? Also, what wiring would I need? Specifically, which pins on the USB (30/31 on demo board) connect to which pins on the DB9 serial port on the PC? Did I get that right?
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Doing my part to keep the Commodore 64 alive!
http://www.commodorestuff.com
·
On the object give it the pins
PC_rx = 31
PC_tx = 30
and this will work.
Note that you need to "CLOSE" the port while you program then quickly "OPEN" the port afterwards before the waitcnt delay finnishes.
James
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Doing my part to keep the Commodore 64 alive!
http://www.commodorestuff.com
·
-or-
On a Windows box look in the ports list in your device manager-
You do not need the USB2SER, I used it simply to keep me from having to open and close the port (not really that big a deal)-
It is funny to think, a PC is simply a slave storage device to the Propeller in this setup [noparse]:)[/noparse]
I would think that this is a development step, and that the use of ICs would be the ultimate goal...
Ryan
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Ryan Clarke
Parallax Tech Support
RClarke@Parallax.com
As far as the MMC code, great! And, if I recall from the documentation, MMC and SD are identicale, arent they?
If not, then I'll just hop on out and get a MMC card... no biggie...
And Ryan, Yes, I'm laughin at the fact that in essence we are making the PC the slave to the propeller....
Woot! this is flyin!
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Just tossing my two bits worth into the bit bucket
KK
·
So now I can start testing my emulator code!!!
James, it would be much easier if I could use the VB source code - do you mind posting that?
Thanks,
Goog
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Doing my part to keep the Commodore 64 alive!
http://www.commodorestuff.com
Post Edited (Goog) : 6/16/2006 7:41:04 PM GMT
Once you load your ROM files into this RAM file/program, save it.· You will never have to run this program again after that, unless you delete or corrupt the file.
Sorry, I cannot post the ROM files - copyright laws say you have to have rights to the ROM data (which basically means you must own a Commodore 64).· You can find the ROM files on the Internet.· If you are really adventurous, you could pop the chips out of the C64, plug them into your Propeller breadboard·and download the data.· That might just be a fun project in itself, huh? [noparse]:)[/noparse]
--Goog
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Doing my part to keep the Commodore 64 alive!
http://www.commodorestuff.com
Yeah I can post vb code - once i've got all the updates going. (not at home till tomorrow - so hopefully Sunday PM or Monday)
The SD and MMC are similar - the spec says you can use a MMC in an SD device but not the other way arround. I've only got MMC card code so best get MMC/RS (reduced size) if you want to use my Object.
James
Here's something else that will be cool: I am going to use another COG for the VIC chip emulation - it is the chip that does all of the video work. I have it launched in a new COG right now and it monitors the bus activity and outputs the data to the TV terminal. Way cool!
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Doing my part to keep the Commodore 64 alive!
http://www.commodorestuff.com
·
The differences between MMC and SD is that the SD card is slightly thicker than the MMC card, and that it has some additional 'security' functions. (SD = Secure Digital)
Not that I've ever heard of anyone ever using those functions...
In all other aspects the cards are identical.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Don't visit my new website...
The only thing that would be hard to emulate in that sound chip would be the analog filter that was built in, but other then that it should be a walk in the park.
As advanced as the SID was for it's time, it's not all that complex.
Still composers made some really cool tunes for that thing and still do to this day.
Maybe I'll get out my old datasheet of the thing and write some firmware to emulate it on a COG. That is after I get done working on my current Sound Co-Processor design.
Well keep us all posted! This seems like a really cool project.
--Andrew Arsenault
P.S. I write my first programs and music on the C64 long ago. (lol) ^^
Yeah, I wrote a lot of C64 when I was a young teen as well - in fact, the reason I am doing this emulator to begin with is so that I can understand all of those little things I never did being that young! What fun!!!
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Doing my part to keep the Commodore 64 alive!
http://www.commodorestuff.com
·
www.romanblack.com/picsound.htm
even has a .exe for converting .wav files to the required format.
Might work for the Propeller.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Sound programming is what I normally do anyway. (lol)
The SID shouldn't be that hard to emulate. Compared to some of the other Sound Co-processor/Generater designs I've wrote in the past and am currently working on, It's fairly simple and wouldn't be that hard to do.
Plus it'll be fun coding the Mos6581 in ASM anyway. ^^
I just can't wait until this thing says "PRESS PLAY ON TAPE" *grins*
--Andrew Arsenault
This is version 1.1 of the bigMem object and c64RAM vb6 project.· Both are attached in ZIP format.
The following changes have been made:
1)· LONG variable support - tested with 10_000_000 + numbers
2)· Smaller and faster ramsave.txt files
3)· Timeout on readValue (changed from readByte) to allow program to continue in the event of comm failure(s)
(the compiled version of the vb6 app is in the ZIP file - for those without V-Studio 6 SP6)
Let me know how you get on,
James
I'm in the process of testing... The interaction between the Propeller and the PC Ram is great - it seems to be plenty fast for this testing phase.
I am having difficulty with some object interaction and object memory.· I need some answers on how objects relate to each other in SPIN.· I really need to have the ability to use "multiuse" or shared objects.· Any thoughts? (please answer in the thread below)··See my other post here:
http://forums.parallax.com/showthread.php?p=592564
Thanks,
Goog
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Doing my part to keep the Commodore 64 alive!
http://www.commodorestuff.com
·