Advertisement
GStreamer Conference 2013, 22-23 Oct, Edinburgh
GStreamer, Embedded Linux, Android, VoD, Smooth Streaming, DRM, RTSP, HEVC, PulseAudio, OpenGL. Register now to attend.
| |||||||||||||
Garrett: Implementing UEFI Boot to ZorkGarrett: Implementing UEFI Boot to ZorkPosted Sep 24, 2013 5:17 UTC (Tue) by eru (subscriber, #2753)In reply to: Garrett: Implementing UEFI Boot to Zork by atai Parent article: Garrett: Implementing UEFI Boot to Zork How about directly boot into a Commodore 64. Runs just like an 8-bit machine Or perhaps what the Commodore 64 (or similar machines of that era) would have looked like with a 64-bit processor and gigabytes of memory, but still with a BASIC interpreter hand-coded in assembler? (A computer from an alternate reality, where programming languages and operating systems remained undeveloped). Would attain an awesome score in the old David Ahl's Creative Computing BASIC benchmark...
(Log in to post comments)
Garrett: Implementing UEFI Boot to Zork Posted Sep 24, 2013 18:02 UTC (Tue) by branden (subscriber, #7029) [Link]
You'd need to add support for (at least) wider integral data types. Otherwise you'd still only have 64kB of RAM. Those old interpreted BASICs all figured they knew where the top of RAM was ($7FFF, $BFFF, or $FFFF).
Plus there would be the obvious problems with attempting to PEEK or POKE areas above the 64kB "barrier", and PRINT MEM itself would either report the same old low value (I still remember that it was 48340 on Radio Shack Level II BASIC on the TRS-80 Model I...), or, if it were somehow aware of all those gigs of RAM, performing this operation would result in an integer overflow. :)
Garrett: Implementing UEFI Boot to Zork Posted Sep 25, 2013 0:21 UTC (Wed) by davidstrauss (subscriber, #85867) [Link]
> You'd need to add support for (at least) wider integral data types. Otherwise you'd still only have 64kB of RAM.
Or use multi-level bank-switching.
Garrett: Implementing UEFI Boot to Zork Posted Sep 25, 2013 5:16 UTC (Wed) by dlang (✭ supporter ✭, #313) [Link]
and remember that the c64 already supported bank switching so that you could have either the ROM or RAM at a particular location (and it ran MUCH faster if you copied ROM to RAM and switched to the all RAM config)
Garrett: Implementing UEFI Boot to Zork Posted Sep 26, 2013 18:18 UTC (Thu) by nix (subscriber, #2304) [Link]
It supported multi-level bank switching, no less: $D000-$DFFF could not only hold RAM and the "character ROM" which held images of the glyphs, but also the I/O area where the 6510's I/O ports were exposed.
To add even more confusion, the VIC chip always saw the character ROM at this position (you could copy the glyphs elsewhere and modify them, then ask it to look elsewhere in memory: elsewhere, as I recall, it always saw RAM). Meanwhile, the 6510 by default saw the I/O ports, though you could change that in the usual way. So the shape of the memory map varied depending on what chip you were talking about.
The C64 was a *fun* architecture... it's just a shame that everyone's first program had to be to write an assembler in raw machine language or in that horrific crippled dialect of MS BASIC. As a previous Sinclair ZX81 user, I was not tempted by the BASIC route at all! I'd seen a *real* BASIC, after all (and in the end Sinclair gave us SuperBASIC, which was very nearly a real language).
Garrett: Implementing UEFI Boot to Zork Posted Sep 25, 2013 4:00 UTC (Wed) by eru (subscriber, #2753) [Link] Naturally the alternate-reality ROM BASIC would have a wider integer type, since it would be running on a 64-bit CPU! The 1970's originals had 16-bit integers only because supporting wider ones would have meant more CPU and memory usage. The 6502 family (in Apple II, the 8-bit Commodore computers and many others) actually had only 8-bit arithmetic operations, but 8-bit integers would have been a bit too limiting even then... The alternate-reality coder could also generously widen other types, like make floating-point variables 8 bytes, instead of 4 or 6 that were typical, and allow strings longer than 256 characters. He might even support more than 2 significant characters in identifiers. I wonder if a BASIC like this would still fit into 16Kb? x86_86 code is not as compact as 6502, but on the other hand, the ROM would not have to contain software floating-point routines any more.
Garrett: Implementing UEFI Boot to Zork Posted Sep 26, 2013 2:06 UTC (Thu) by zlynx (subscriber, #2285) [Link]
It is funny but Microsoft Research has developed almost this system, called Singularity.
Okay, okay, it is actually an operating system implemented in .NET but I could easily see it running a Visual Basic shell.
Garrett: Implementing UEFI Boot to Zork Posted Oct 7, 2013 12:35 UTC (Mon) by basdebakker (guest, #60977) [Link]
Don't assume that hand coded assembly means fast. I don't know about the Commodore 64, but I did own a ZX Spectrum. The BASIC interpreter would do linear searches to find the line to GOTO or the variable to use. Every time it needed them. You could actually improve performance by moving frequently used code to the beginning of the program.
|
|||||||||||||