After you answer one, you must post one yourself.
OK. I'll go first. Easy one:
POKE 53281, 6
Answer: Turns the screen background a dark blue.
-
Minh
WOOH! WOOH!
-
Minh
WOOH! WOOH!
Haha! You don't have a C-64 emulator running on the PSP yet? I believe one's out for the PocketPC.
-
Beer28 wrote:I even have my fastload cartrige, I bet that's worth millions today
(jk)
BTW: I just reread a little of my book, and it said that the C64 had an IVT table but instead of interupt handlers persay they were all jmp addresses for call instructions( no real interupts for system calls ), and the os would rtn to pop the caller address off the stack and turn the flow back to your program.
So there was a kernal, but it was set up different than x86. Very similar but a different implementation. There was also mapped memory, so that was neat to read. The entire OS and basic was in the 20k of ROM and of the 64k of RAM, only 32k was userspace.
It resembles a MCU alot.
It should as it was a motorola 6802 or 6810 (can't remember) which is (i think) in the same family as the 68HC11 -
figuerres
???
Beer28 wrote:I even have my fastload cartrige, I bet that's worth millions today (jk)
BTW: I just reread a little of my book, and it said that the C64 had an IVT table but instead of interupt handlers persay they were all jmp addresses for call instructions( no real interupts for system calls ), and the os would rtn to pop the caller address off the stack and turn the flow back to your program.
So there was a kernal, but it was set up different than x86. Very similar but a different implementation. There was also mapped memory, so that was neat to read. The entire OS and basic was in the 20k of ROM and of the 64k of RAM, only 32k was userspace.
It resembles a MCU alot.
alctually all of it was "userspace" is you knew how to map it...
on the 128 the MMU was killa!
and it had Abacus Basic 128 broke for a while...
I sent them via Genne Network the info on how to fix a bad bug...
when they ported the compiler they forgot to add code to handle the 128's bank-switching and MMU chip.
if you wrote modem code with basic 128 it would randomly lock up....
I showed them what was wrong...
and got a box of all the Abacus / Data Beker developer stuff they had back then....
-
figuerres
???
Buzza wrote:
Beer28 wrote: I even have my fastload cartrige, I bet that's worth millions today (jk)
BTW: I just reread a little of my book, and it said that the C64 had an IVT table but instead of interupt handlers persay they were all jmp addresses for call instructions( no real interupts for system calls ), and the os would rtn to pop the caller address off the stack and turn the flow back to your program.
So there was a kernal, but it was set up different than x86. Very similar but a different implementation. There was also mapped memory, so that was neat to read. The entire OS and basic was in the 20k of ROM and of the 64k of RAM, only 32k was userspace.
It resembles a MCU alot.
It should as it was a motorola 6802 or 6810 (can't remember) which is (i think) in the same family as the 68HC11
C64 was a 6510 as I recall
the 128 I think was the 6810
but thats my recall from almost 20 years back... -
Minh
WOOH! WOOH!
What is the result of this statement:
READY
Answer: The BASIC interpreter sees this as READ Y, so since there's no DATA statement, you'd get an OUT OF DATA ERROR. -
Minh
WOOH! WOOH!
What is this address?
53248
Anser: The VIC -
Minh
WOOH! WOOH!
What is this address?
54272
Answer: The SID -
Minh
WOOH! WOOH!
Why does multi-color mode both rocks & sucks at the same time?
Answer: Multi-color mode lets you double the # of colors in an 8x8 are from 2 to 4, but it lowers the resolution of that area to 4x8. -
Minh
WOOH! WOOH!
I'm having too much fun. By default, where does screen memory start?
Answer: 1024. -
Minh
WOOH! WOOH!
There's actually RAM underneath the 20K of ROM. If you're not using the BASIC interpreter, you can expose the RAM and use that yourself.Beer28 wrote:There was also mapped memory, so that was neat to read. The entire OS and basic was in the 20k of ROM and of the 64k of RAM, only 32k was userspace.
You can even interupts what line the TV is refreshing. This lets the C64 has more than 8 sprites by repositioning them.
-
My Favorite Games:
Head over Heels
The Last Ninja
The Last Ninja II
Ultima Series (I think 1 - 3) -
figuerres
???
Beer28 wrote:
Minh wrote: There's actually RAM underneath the 20K of ROM. If you're not using the BASIC interpreter, you can expose the RAM and use that yourself.
You can even interupts what line the TV is refreshing. This lets the C64 has more than 8 sprites by repositioning them.
There are no software interupts for system calls though, that's what I meant. I looked at the map of the ROM and RAM in the book last night. Everything as far as kernal calls, had to be called explicitly from the application as if you are calling a regular function in 8086.
There was no mapping syscalls with an IVT and interupts like on the x86.
The c64 programmers reference guide has all the set RAM addresses of the kernal entry point addresses, where it's an address in the ROM where the syscall starts.
What's really wierd is that the ROM is such a big part of the system. You never see that anymore on x86. That's why the c64 was so fast though, the system was run strait out of the ROM and never had to be loaded.
If the IBM PC specification wasn't so beaten into hardware makers brains, it would be cool to experiment and make a computer where the linux kernal resides in ROM, or a USB stick.
I wish the motherboards we can buy for x86 would include an extra slot for ROM, where we could store persistent data.
How come we can't put ROM on our x86 motherboards?
If we had ROM we could do so much more.
FLash is better....
but if you burn a bunch of code to rom/flash then you are stuck - in a production world if you had 2 million systems with a rom / flash and you need them to update.... failed flash == dead pc
rom chips == take it to a shop
but viruses have a bad time with rom based code ! -
Sven Groot
I'm Commander Shepard and this is my favourite store on the Citadel.
figuerres wrote:FLash is better....
Flash is just a faster type of EEPROM. -
figuerres
???
Sven Groot wrote:
figuerres wrote: FLash is better....
Flash is just a faster type of EEPROM.
I know....
just that ROM = Write once
Flash = write at least a few times....
-
Beer28 wrote:You can rewrite ROM infinately.
How so? From what I remember of ROM chips (at least in the past, but I haven't looked into them for quite some time) they were Read-Only-Memory...as in, burned in at the factory. Then, along came EPROMs (Eraseable, Programmable, Read-Only-Memory) and other variants.
I do agree that more code should be put into the ROM (like the ol' days). Wouldn't it be possible to burn an OS kernel (perhaps Linux) onto a ROM? Or at least part of it? Maybe the sections that have remained the most stable over the years? Not the entire thing, however.
P.S. Wow has this thread veered off topic. What's new, though.
P.P.S. Hey, what's up with Transmeta by the way? Have they filed bankruptcy yet? I thought I heard they were being sold. -
Sven Groot
I'm Commander Shepard and this is my favourite store on the Citadel.
Beer28 wrote:You can rewrite ROM infinately.
No you can't. You cannot write ROM at all.
ROM: Contents are decided in the factory where the ROM is produced. Connections are hardwired and cannot be changed.
PROM: Programmable ROM. The ROM is blank when produced, and can be programmed exactly once. Once the PROM is programmed, its contents can never be changed.
EPROM: Erasable Programmable ROM. Same as with PROM, only the programming can be erased afterwards, after which you can reprogram the ROM with new contents. The ROM is erased one byte at a time using UV radiation.
EEPROM: Electronically Erasable Programmable ROM. Same as EPROM, only it's erased using an electric field rather than UV.
Flash memory: EEPROM that is erased per block rather than per byte, and can therefore be rewritten much faster. -
ScanIAm
Edgar Allen Potato.
I don't know if they still exist, but those were actually very popular for quick booting servers in telephony. The form factor was a box the size of a (larger) hard drive. Inside was 8 rows of SIMMs and a SCSI or IDE connection as well as a power supply connection. The power was kept on constantly to keep the memory running so that if the machines had to be rebooted, they would do so and come back up again in seconds instead of minutes. This was in the days when there was a 2 gig limit for the OS drive so they'd have 2 gigs with nothing but the OS installed. The hard drives would have the rest.
Very, very expensive at the time, but they worked quite well.
Edit: Aha!
http://www.google.com/search?hl=en&lr=&c2coff=1&rls=GGLD%2CGGLD%3A2004-10%2CGGLD%3Aen&q=solid+state+disk+drive
Thread Closed
This thread is kinda stale and has been closed but if you'd like to continue the conversation, please create a new thread in our Forums,
or Contact Us and let us know.