Goog said... ·My goal is to have a C64 computer (using the Propeller), placing it in an old PC laptop and interfacing it to the VGA LCD screen.· Old laptops are easy to acquire on ebay or at garage sales... the old hardware is ideal because 1) LCD screen, 2) Likely it will have 2 serial ports which can serve as the joystick inputs (DB9 connectors). 3) built-in keyboard.· I'll basically remove the guts and place the propeller circuit board inside, hooking up the wires to the devices I plan to use accordingly.
It will be very hard, if not impossible to interface ANYTHING to a laptop LCD, for the one reason that they are NOT VGA. Pretty much every manufacturer of laptop uses a different proprietary format to get video into the LCD.
Other then that, this project seems really cool. Can't wait to see it when it's completley done!
OH, I was unaware of that. I figured there was some connector internal that I could use. Oh, well. The project will still move on.
The emulator is coming along... it is mostly working for phase 1 (just getting it to boot with text), but there is a bug somewhere in there that I am still tracking down. It is a difficult task - especially since the same code works in my PC version. It must have to do with the syntax conversion to SPIN. I will keep at it!
Most LCDs have two rows of ICs, one for the 'row select' and one for the 'column select' controls. displaying a picture is then a matter of clocking through each pixel, row by row, and transmitting the bit/byte/whatever needed to set the correct colour on that pixel.
The problem is that those driver ICs doesn't have any memory, so the processor needs to refresh the picture periodically, and usually at a set speed.
But, if you can find the datasheets for the ICs used, it may be possible to do it. It just won't be easy...
On the other hand, ever seen a Z88 laptop?
It has a 640x96 B/W LCD, and that is controlled with just the humble Z80 cpu.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Don't visit my new website...
Yeah, I'm open to just about any format - I just want to be able to take my "Commodore 64 Laptop" anywhere and play my old favorite games and do my Commodore programming. It is quite a ways off, though - still have to get it working.
Update: The emulator code seems to be doing its RAM test just fine - to a point... this is where the program is now hanging. The RAM test takes a really long time, reading, writing, and then reading again. It gets to a certain point and just seems to go off into no-man's land. The Kernal code does several loops, testing each memory location. Then... the C64 Ram! program crashes. I think it could be the COMM control - it might have a memory leak or something. Consider how many reads/writes this thing does.
I'm not so sure this will be the best solution. I might just have to do this on those RAMTRON chips - even for testing. Besides - it is too slow. It would probably take about 45 minutes to just get through the C64 boot-up process!
I'm sorry I did not get to it yet... I just now placed my order with Ramtron - hopefully that will be a simple enough process getting those samples. I also have to find an adaptor for those chips to plug in to my breadboard. I will post an update.
What chips did you order? Because Digikey.com has some adaptors in stock that might work.
The FRAMs should work well for prototyping because once you load the c64's ROMs onto them, then the memory should stay in there forever. Also part of the chip could be used as the systems RAM I would think. Well let me know what you find! ^^
I ordered the 64K serial FRAM chip (I think it was the FM24CL64). Have I gotten any response from Ramtron yet? No. What does it take to get these chips?
In my long absence from the forum, has anyone found any other large memory solution that I could try?
I will try and call them directly tomorrow. I will also look at that Digikey part. Thanks!
Ah - sorry I posted before looking... I can order these from Mouser.com. I'll let you all know what happens, if I can get them working. Has anyone successfully hooked up the FRAM chips? Anything I need to know?
Hi all - thanks for being patient.· I was in Las Vegas at the CommVEx (Commodore Vegas Expo), learning new things and showing my progress on the Propeller C-64 emulator.· Of course, it didn't fully work yet, but it was somewhat demo-able, showing the reads and writes on the bus to the monitor.
I finally got the parts I needed - the FRAM chips and the SOIC->DIP adapter.· I soldered the surface mount chip to the adapter and I am ready to hook it up.· However, due to my lack of electronics skills, I was hoping someone here could help me hook it up correctly.· Here is the datasheet for the chip:
I spent all evening/night/and now morning getting the emulator to do something.· It is still pretty slow, even with the memory chips - but that is okay! It was taking forever for it to boot up because it does a RAM test, which is slowly emulated.· But I cheated - I bypassed the routine where it figures out the top of memory and faked it out.· So it doesn't do the RAM test anymore (for now) - instead, it steadily continues its boot-up procedure.· And you'll love the results!
I posted a video on my Web site so you can see just how slow it is.· Remember, this is all written in SPIN.· I will be converting it to Assembly later on, once it works better.
Today marks the milestone where I successfully ran the emulator, completely booting to its "Ready." prompt.· This was really exciting - yesterday's post was really only "almost working" because it was coming back with an error on the screen.· This was due to a bug that took me all day to find.· Turns out it was·in the BEQ emulation.· Apparently, I forgot to port an ABS (Absolute Value) function to SPIN from my original .NET code.· I'm so glad it works now.· Check out the screen shot! (I know, it looks similar to yesterday's post, but it is definitely cooler because it really works now).
Also, check out my massive debugging system, which displays the state of all of the C64's registers, stack pointer, and program counter.· I can execute an opcode one at a time, put breakpoints in to stop at a certain memory location (essentially freezing the C64 dead in its tracks), change register values or even set the PC to a new spot.
Calling All Programmers!!!
Here are·the next steps I need to take.· I could use some help with most of these tasks - anyone who·helps will get credits in·my final version
Start converting code to Assembly language
Before this emulator is even useful, it needs to be MUCH FASTER.· Since I haven't studied up on Propeller Assembly (yet), I could really use some help here - For anyone who wants to help, I will "serve" a few functions at a time to each of my helpers.· Keeping the Assembly code similar to the SPIN functions will help keep things simple.
Graphics Object/Driver
It would be great if I didn't have to do this one - I would like it if someone could develop a graphics driver that outputs a 320x200 image.· Each vertical row would be drawn one line at a time, dot-by-dot.· It must be light, it must be fast, and it must be easy to use - for instance, I imagine something like this:
Repeat Row From 1 To 200
Repeat Col From 1 To 320
'Fetch pixel/color information from VIC chip
Color := 0 'Color value for black
objScreen.Color := 0
objScreen.Plot(c, y, Color)
Of course, this would be converted to Assembly, too... The driver doesn't really need a whole lot of functionality because the C64 handles all of the drawing of graphics, sprites, characters, etc.· As long as I can draw an entire row, that is all I need (I think).· I don't really want to use the existing graphics diver and tv object because they are bloated with things - I would much rather have a stripped-down, specific object for this task.
Other Chip Emulation
Up to now, I have really only emulated the 6510 processor and memory management.· It simply fetches an opcode, decodes it, and then executes it.· I am using the existing graphics/tv objects to output text when screen memory is written-to.· That is why you can see the startup screen and ready prompt.· There are other vital chips to emulate, such as sound (SID), video (VIC), CIA (clock, etc.), 1541 Disk and/or drive emulation, etc.
Once these pieces are ready, we should be able to add on some sort of SD card or other memory device to store all of your favorite programs (Dino Eggs, Jumpman, Lode Runner,·Oil's Well, and Castles of Dr. Creep·are a few of my faves)!
·· Are you going for 100% emulation?· I was curious because I remember my days of modifying & customizing the ROM...In order to squeeze in custom functions we would replace blocks of ROM such as the Tape Loader and things like that by dropping in an EEPROM.And then there's the fact that sections of ROM could be switched in/out to expose underlying RAM...Many of the last software for the C=64 took advantage of that to gain more available RAM.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔ Chris Savage Parallax Tech Support csavage@parallax.com
I tend to program like an oldschool demoscener and I see potential for (with what I've seen about Propeller) to emulate various vintage
systems, however I have my own tools and would not be able to do anything with the propeller UNLESS... FOR EXAMPLE...
I could have the "programming specifications" and "hardware specifications" to write a Propeller-Programmer Program on,
and directly connect the chip to, the system being emulated... In this case a C64,
Is this info available? I am considering a project now that, otherwise, would be more convenient to do with less than 8 Pics or Ubicoms.
I'm not asking specifically how to connect the Propeller to a C64..., if I had them, I would know how to do it.
Just curious. My collection of vintage computers lacks a C64 so there is not much I could add to this project now.
(unless perhaps there is a faithful C64 emulator for MSDOS to use)
Sorry it took so long to reply - my company has a release going out soon, so it has kept me quite busy this week.
First of all... Programmertanner asked about giving out the code.· I am not quite sure what to do at this point.· At least in its early stages, I will most likely keep the source closed - that way, I can keep control over releases and not have too many versions floating around.· But I do want to share.· I know people want to learn some cool things, as do I.· I'll probably post code near the end of the project, but I can't say for sure at this point what I'll be doing.· For anyone who wants to try this thing on their own, just let me know if you have the hardware that I am using (or similar) so that I can give you the binary dump of the compiled program.· I am basically using the Demo board (rev. c) with 2 additional FRAM EEPROMs hooked up.
Next, Chris -- to answer your question.· The emulator will be as close to 100% as possible, but I am still learning things about the C64's architecture that are not necessarily best emulated to the same degree.· It does emulate the ROM/RAM switching, so you should be able to disable the ROMs and write to the underlying RAM for more programming.· Of course, this would require that the ROM images are stored in a non-destructive chip, which means that I would have to have a way to keep the ROM data without overwriting it.· Since I only have 64K of total memory on the EEPROMs, any reads and writes to the ROM portions will overwrite that data.· If I add an additional 20K, I can keep a copy of the ROM image and just protect it from being written to.· Does that make sense?
One other thing about your question... you will certainly be able to replace certain Kernal locations with your own data.· For instance, setting the default device number to 8 (Disk Drive) instead of 1 (Tape Drive), or setting your own default color scheme.· You can change these values before you load the ROM image with my C64 ROM loader program.· That reminds me - I have to post my newest version here, which I will do soon.
Javalin - great! That will be near the end of the project, anyway, so no big rush.
Lastly, VIMX - Not sure exactly what you're asking about... I am merely emulating the C64, so any programs that you want to run on the C64 would run on this emulator without having to know about the Propeller's underlying coding system (SPIN/Assembly).· There is nothing to hook up to a physical C64.
Eeek! I just fried my propeller board. I put one of my EEPROM chips on backwards (doh!) and it got super hot. Now it isn't working. I ordered a new one - so here's a tip for all of you: Make sure your PIN 1 is aligned properly :S
I was adding another EEPROM because I needed to do some logging of commands. There is some bug that I can't find, so I thought this would be the easiest way to find it - log every command, address, register, etc. and compare it to my PC version of the emulator, which doesn't have the bug (it will log the same things). Then, I just compare the two files to see where there is a difference. Now I have to wait 'til my new demo board comes [noparse]:([/noparse]
Goog...
Just a silly idea...
Have two banks of 64K eeprom... one representing ROM, the other representing RAM...
Have the emulator know which eeprom to read / write from. This will give you a real good emulation of ram/rom image switching.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Propeller + Hardware - extra bits for the bit bucket =· 1 Coffeeless KaosKidd
·
Not a silly idea... in fact, it is a pretty good one. The C64 actually only has 20K in ROM, so I wouldn't need a full 64K. In fact, I was considering doing this anyway, because if a program ever writes to a ROM location (after reconfiguring the memory layout, of course), I have no way to restore it back to its original image without re-loading it. I was considering keeping the ROM images each in their own chips, just for clarity and to keep true to the original layout, but that might be a little overboard
Goog said...
Eeek! I just fried my propeller board. I put one of my EEPROM chips on backwards (doh!) and it got super hot. Now it isn't working. I ordered a new one - so here's a tip for all of you: Make sure your PIN 1 is aligned properly :S
FYI. After somehow putting ICs in backwards several times, my method was to put a 'dot' of LiquidPaper™ on the IC at the pin#1 position; let it dry. Like when using ZIF socket, for instance, where use may be frequent. The dotted IC maybe isn't very 'pretty' but better than a dead one. Exacto can scrape (most) off at a later date.
Goog said...
Eeek! I just fried my propeller board. I put one of my EEPROM chips on backwards (doh!) and it got super hot. Now it isn't working. I ordered a new one - so here's a tip for all of you: Make sure your PIN 1 is aligned properly :S
FYI. After somehow putting ICs in backwards several times, my method was to put a 'dot' of LiquidPaper™ on the IC at the pin#1 position; let it dry. Like when using ZIF socket, for instance, where use may be frequent. The dotted IC maybe isn't very 'pretty' but better than a dead one. Exacto can scrape (most) off at a later date.
I'm guessing from Goog's posts that it wasn't a case of having the chip the wrong way around, but that he inserted the chip one or more pins too far up or down in the socket, so the Liquid Paper trick wouldn't have helped much.
I got my new demo board a few days ago. Turns out I didn't fry my board after all. Here's what happened:
When I decided to put my extra EEPROM on for logging, I was so eager to get it going that I put it on backwards without taking the time to look at pin 1 (the white out idea, though good, wouldn't have helped any more than the little dot on pin 1 - I was just moving too fast to look close enough. And no, I didn't shift it, I put it on backwards :S). Now I have two fully-functioning demo boards [noparse];)[/noparse]
Anyway, putting the logging chip in there meant that I had to have code to turn on/off the log. After writing the code, I was able to test it out, which is when I realized that the board was working erradically and noticed the chip on backwards. So it appeared as if the chip messed things up. But when my new board came, I was getting the same strange behavior. After investigating further, I realized that it wasn't the board - it was that my program was bursting at 32K. I'm certain that it didn't have enough stack space to work properly. After removing the code for the log, it worked fine once again. But now I have no way to log the activity.
I guess I'll have to start optimizing and converting to Assembly now. That is fine, but I really wanted to find this little bug first. For those who want to know what the bug is, it is this: After the C64 "boots up", it displays the normal message just fine and provides a Ready prompt. When I enter a BASIC line, such as 10 PRINT "HI"<ENTER>, the cursor moves down, as expected, but the BASIC program is not stored. In other words, when pressing ENTER after the line, it doesn't store the line in BASIC properly. It does store some of it, but not all of it. That leads me to believe there is a bug in one of my emulated opcodes. The funny thing is that I had this same exact problem when I wrote the PC version, but I can't for the life of me remember what it was.
Finally - an update.· Here's a quick summary of what's been taking so long:
The C64 would boot just fine, which led me to believe that all the opcodes were working just fine.· After the Ready prompt, I would type a program, such as 10 PRINT "HELLO" but the program would not store correctly.· I found out tonight that typing something like LET A=10 would give a SYNTAX ERROR.· I spent quite a while trying to step through the code, comparing it to my .NET version on the PC, with no luck.
After trying the LET A=10 tonight, I remembered what it could be.· It turns out that the ASCII values from the keyboard are not the same ones that the C64 expects.· I have to either type in UPPER case or translate the keystrokes in code.· Once I tried that, everything seems to work perfectly.· Take a look at the screen shot.
Now I am ready to move on.· I will start handing out functions to people who wish to help translate the SPIN code to Assembly code.
Whew! I am so glad that I finally figured it out!!!
Comments
Other then that, this project seems really cool. Can't wait to see it when it's completley done!
Post Edited (karbonus) : 6/27/2006 8:39:12 PM GMT
The emulator is coming along... it is mostly working for phase 1 (just getting it to boot with text), but there is a bug somewhere in there that I am still tracking down. It is a difficult task - especially since the same code works in my PC version. It must have to do with the syntax conversion to SPIN. I will keep at it!
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Doing my part to keep the Commodore 64 alive!
http://www.commodorestuff.com
·
Most LCDs have two rows of ICs, one for the 'row select' and one for the 'column select' controls. displaying a picture is then a matter of clocking through each pixel, row by row, and transmitting the bit/byte/whatever needed to set the correct colour on that pixel.
The problem is that those driver ICs doesn't have any memory, so the processor needs to refresh the picture periodically, and usually at a set speed.
But, if you can find the datasheets for the ICs used, it may be possible to do it. It just won't be easy...
On the other hand, ever seen a Z88 laptop?
It has a 640x96 B/W LCD, and that is controlled with just the humble Z80 cpu.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Don't visit my new website...
Why not use the small TV that Parallax sells, that and a PCB would make a small and quite cool C64.
Advantages being that the code is already there and tested!
http://www.parallax.com/detail.asp?product_id=603-32000
James
Update: The emulator code seems to be doing its RAM test just fine - to a point... this is where the program is now hanging. The RAM test takes a really long time, reading, writing, and then reading again. It gets to a certain point and just seems to go off into no-man's land. The Kernal code does several loops, testing each memory location. Then... the C64 Ram! program crashes. I think it could be the COMM control - it might have a memory leak or something. Consider how many reads/writes this thing does.
I'm not so sure this will be the best solution. I might just have to do this on those RAMTRON chips - even for testing. Besides - it is too slow. It would probably take about 45 minutes to just get through the C64 boot-up process!
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Doing my part to keep the Commodore 64 alive!
http://www.commodorestuff.com
·
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Doing my part to keep the Commodore 64 alive!
http://www.commodorestuff.com
·
The FRAMs should work well for prototyping because once you load the c64's ROMs onto them, then the memory should stay in there forever. Also part of the chip could be used as the systems RAM I would think. Well let me know what you find! ^^
Thanks!
--Andrew
In my long absence from the forum, has anyone found any other large memory solution that I could try?
I will try and call them directly tomorrow. I will also look at that Digikey part. Thanks!
Goog
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Doing my part to keep the Commodore 64 alive!
http://www.commodorestuff.com
·
Thanks,
Goog
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Doing my part to keep the Commodore 64 alive!
http://www.commodorestuff.com
·
I finally got the parts I needed - the FRAM chips and the SOIC->DIP adapter.· I soldered the surface mount chip to the adapter and I am ready to hook it up.· However, due to my lack of electronics skills, I was hoping someone here could help me hook it up correctly.· Here is the datasheet for the chip:
http://www.ramtron.com/lib/literature/datasheets/FM24CL64ds_r3.1.pdf
Also, is there a routine that is already done that I can just re-use to do the communication?
Maybe I can get something posted this weekend if it is all working.
Goog
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Doing my part to keep the Commodore 64 alive!
http://www.commodorestuff.com
·
I spent all evening/night/and now morning getting the emulator to do something.· It is still pretty slow, even with the memory chips - but that is okay! It was taking forever for it to boot up because it does a RAM test, which is slowly emulated.· But I cheated - I bypassed the routine where it figures out the top of memory and faked it out.· So it doesn't do the RAM test anymore (for now) - instead, it steadily continues its boot-up procedure.· And you'll love the results!
I posted a video on my Web site so you can see just how slow it is.· Remember, this is all written in SPIN.· I will be converting it to Assembly later on, once it works better.
I'll update more later... I'm very sleepy!
Goog
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Doing my part to keep the Commodore 64 alive!
http://www.commodorestuff.com
Also, check out my massive debugging system, which displays the state of all of the C64's registers, stack pointer, and program counter.· I can execute an opcode one at a time, put breakpoints in to stop at a certain memory location (essentially freezing the C64 dead in its tracks), change register values or even set the PC to a new spot.
Calling All Programmers!!!
Here are·the next steps I need to take.· I could use some help with most of these tasks - anyone who·helps will get credits in·my final version
Start converting code to Assembly language
Before this emulator is even useful, it needs to be MUCH FASTER.· Since I haven't studied up on Propeller Assembly (yet), I could really use some help here - For anyone who wants to help, I will "serve" a few functions at a time to each of my helpers.· Keeping the Assembly code similar to the SPIN functions will help keep things simple.
Graphics Object/Driver
It would be great if I didn't have to do this one - I would like it if someone could develop a graphics driver that outputs a 320x200 image.· Each vertical row would be drawn one line at a time, dot-by-dot.· It must be light, it must be fast, and it must be easy to use - for instance, I imagine something like this:
Repeat Row From 1 To 200 Repeat Col From 1 To 320 'Fetch pixel/color information from VIC chip Color := 0 'Color value for black objScreen.Color := 0 objScreen.Plot(c, y, Color)Of course, this would be converted to Assembly, too... The driver doesn't really need a whole lot of functionality because the C64 handles all of the drawing of graphics, sprites, characters, etc.· As long as I can draw an entire row, that is all I need (I think).· I don't really want to use the existing graphics diver and tv object because they are bloated with things - I would much rather have a stripped-down, specific object for this task.
Other Chip Emulation
Up to now, I have really only emulated the 6510 processor and memory management.· It simply fetches an opcode, decodes it, and then executes it.· I am using the existing graphics/tv objects to output text when screen memory is written-to.· That is why you can see the startup screen and ready prompt.· There are other vital chips to emulate, such as sound (SID), video (VIC), CIA (clock, etc.), 1541 Disk and/or drive emulation, etc.
Once these pieces are ready, we should be able to add on some sort of SD card or other memory device to store all of your favorite programs (Dino Eggs, Jumpman, Lode Runner,·Oil's Well, and Castles of Dr. Creep·are a few of my faves)!
Anyone care to help with anything?
Thanks!
Goog
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Doing my part to keep the Commodore 64 alive!
http://www.commodorestuff.com
Very nice. Well i'll spring for the code for the MMC card read/write code.
As we spoke about I have no time for a few weeks, but then I'll get my current code cleaned up, converted to ASM and post it.
James
·· Are you going for 100% emulation?· I was curious because I remember my days of modifying & customizing the ROM...In order to squeeze in custom functions we would replace blocks of ROM such as the Tape Loader and things like that by dropping in an EEPROM.And then there's the fact that sections of ROM could be switched in/out to expose underlying RAM...Many of the last software for the C=64 took advantage of that to gain more available RAM.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Chris Savage
Parallax Tech Support
csavage@parallax.com
systems, however I have my own tools and would not be able to do anything with the propeller UNLESS... FOR EXAMPLE...
I could have the "programming specifications" and "hardware specifications" to write a Propeller-Programmer Program on,
and directly connect the chip to, the system being emulated... In this case a C64,
Is this info available? I am considering a project now that, otherwise, would be more convenient to do with less than 8 Pics or Ubicoms.
I'm not asking specifically how to connect the Propeller to a C64..., if I had them, I would know how to do it.
Just curious. My collection of vintage computers lacks a C64 so there is not much I could add to this project now.
(unless perhaps there is a faithful C64 emulator for MSDOS to use)
First of all... Programmertanner asked about giving out the code.· I am not quite sure what to do at this point.· At least in its early stages, I will most likely keep the source closed - that way, I can keep control over releases and not have too many versions floating around.· But I do want to share.· I know people want to learn some cool things, as do I.· I'll probably post code near the end of the project, but I can't say for sure at this point what I'll be doing.· For anyone who wants to try this thing on their own, just let me know if you have the hardware that I am using (or similar) so that I can give you the binary dump of the compiled program.· I am basically using the Demo board (rev. c) with 2 additional FRAM EEPROMs hooked up.
Next, Chris -- to answer your question.· The emulator will be as close to 100% as possible, but I am still learning things about the C64's architecture that are not necessarily best emulated to the same degree.· It does emulate the ROM/RAM switching, so you should be able to disable the ROMs and write to the underlying RAM for more programming.· Of course, this would require that the ROM images are stored in a non-destructive chip, which means that I would have to have a way to keep the ROM data without overwriting it.· Since I only have 64K of total memory on the EEPROMs, any reads and writes to the ROM portions will overwrite that data.· If I add an additional 20K, I can keep a copy of the ROM image and just protect it from being written to.· Does that make sense?
One other thing about your question... you will certainly be able to replace certain Kernal locations with your own data.· For instance, setting the default device number to 8 (Disk Drive) instead of 1 (Tape Drive), or setting your own default color scheme.· You can change these values before you load the ROM image with my C64 ROM loader program.· That reminds me - I have to post my newest version here, which I will do soon.
Javalin - great! That will be near the end of the project, anyway, so no big rush.
Lastly, VIMX - Not sure exactly what you're asking about... I am merely emulating the C64, so any programs that you want to run on the C64 would run on this emulator without having to know about the Propeller's underlying coding system (SPIN/Assembly).· There is nothing to hook up to a physical C64.
Goog
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Doing my part to keep the Commodore 64 alive!
http://www.commodorestuff.com
·
I was adding another EEPROM because I needed to do some logging of commands. There is some bug that I can't find, so I thought this would be the easiest way to find it - log every command, address, register, etc. and compare it to my PC version of the emulator, which doesn't have the bug (it will log the same things). Then, I just compare the two files to see where there is a difference. Now I have to wait 'til my new demo board comes [noparse]:([/noparse]
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Doing my part to keep the Commodore 64 alive!
http://www.commodorestuff.com
·
Just a silly idea...
Have two banks of 64K eeprom... one representing ROM, the other representing RAM...
Have the emulator know which eeprom to read / write from. This will give you a real good emulation of ram/rom image switching.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Propeller + Hardware - extra bits for the bit bucket =· 1 Coffeeless KaosKidd
·
Not a silly idea... in fact, it is a pretty good one. The C64 actually only has 20K in ROM, so I wouldn't need a full 64K. In fact, I was considering doing this anyway, because if a program ever writes to a ROM location (after reconfiguring the memory layout, of course), I have no way to restore it back to its original image without re-loading it. I was considering keeping the ROM images each in their own chips, just for clarity and to keep true to the original layout, but that might be a little overboard
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Doing my part to keep the Commodore 64 alive!
http://www.commodorestuff.com
·
FYI. After somehow putting ICs in backwards several times, my method was to put a 'dot' of LiquidPaper™ on the IC at the pin#1 position; let it dry. Like when using ZIF socket, for instance, where use may be frequent. The dotted IC maybe isn't very 'pretty' but better than a dead one. Exacto can scrape (most) off at a later date.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Harley Shanko
h.a.s. designn
I'm guessing from Goog's posts that it wasn't a case of having the chip the wrong way around, but that he inserted the chip one or more pins too far up or down in the socket, so the Liquid Paper trick wouldn't have helped much.
When I decided to put my extra EEPROM on for logging, I was so eager to get it going that I put it on backwards without taking the time to look at pin 1 (the white out idea, though good, wouldn't have helped any more than the little dot on pin 1 - I was just moving too fast to look close enough. And no, I didn't shift it, I put it on backwards :S). Now I have two fully-functioning demo boards [noparse];)[/noparse]
Anyway, putting the logging chip in there meant that I had to have code to turn on/off the log. After writing the code, I was able to test it out, which is when I realized that the board was working erradically and noticed the chip on backwards. So it appeared as if the chip messed things up. But when my new board came, I was getting the same strange behavior. After investigating further, I realized that it wasn't the board - it was that my program was bursting at 32K. I'm certain that it didn't have enough stack space to work properly. After removing the code for the log, it worked fine once again. But now I have no way to log the activity.
I guess I'll have to start optimizing and converting to Assembly now. That is fine, but I really wanted to find this little bug first. For those who want to know what the bug is, it is this: After the C64 "boots up", it displays the normal message just fine and provides a Ready prompt. When I enter a BASIC line, such as 10 PRINT "HI"<ENTER>, the cursor moves down, as expected, but the BASIC program is not stored. In other words, when pressing ENTER after the line, it doesn't store the line in BASIC properly. It does store some of it, but not all of it. That leads me to believe there is a bug in one of my emulated opcodes. The funny thing is that I had this same exact problem when I wrote the PC version, but I can't for the life of me remember what it was.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Doing my part to keep the Commodore 64 alive!
http://www.commodorestuff.com
·
I got the datasheet in my office.
It would be a walk in the park, The hardist part would be simulating the analog filter that was on the chip.
'Til then checkout my other propeller sound project:
http://forums.parallax.com/showthread.php?p=604722
--Andrew Arsenault
Finally - an update.· Here's a quick summary of what's been taking so long:
The C64 would boot just fine, which led me to believe that all the opcodes were working just fine.· After the Ready prompt, I would type a program, such as 10 PRINT "HELLO" but the program would not store correctly.· I found out tonight that typing something like LET A=10 would give a SYNTAX ERROR.· I spent quite a while trying to step through the code, comparing it to my .NET version on the PC, with no luck.
After trying the LET A=10 tonight, I remembered what it could be.· It turns out that the ASCII values from the keyboard are not the same ones that the C64 expects.· I have to either type in UPPER case or translate the keystrokes in code.· Once I tried that, everything seems to work perfectly.· Take a look at the screen shot.
Now I am ready to move on.· I will start handing out functions to people who wish to help translate the SPIN code to Assembly code.
Whew! I am so glad that I finally figured it out!!!
Goog
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Doing my part to keep the Commodore 64 alive!
http://www.commodorestuff.com
Well cool.
James
Count me in on this!
The C64 was the computer that got me into programming.