I'll defrag that for the younger audience - the commodore 64 had a slow external disc drive and best explained "The 1541 was very slow in loading programs because of a poorly implemented serial bus, a legacy of the Commodore VIC-20" https://en.wikipedia.org/wiki/Commodore_64_peripherals#Flopp...
The 1541 maintained compatibility with the VIC. The VIC had very slow firmware routines to communicate with its 1540 disk drive because a shift register in the 6522 VIA chip didn't work properly.
The C64 had an improved VIA with a working shift register. The 1541 attached to a C64 was going to be much faster than the 1540 and the VIC. A board rework in the 1541, however, removed a trace needed for the high-speed operation, so the 1541 and a C64 ended up being no faster than a 1540 and a VIC (and actually slower because the VIC-II in the C64 needed to take control of the bus periodically introducing jitter in the communications).
This is a demo running entirely on the 1541 using a hacked together connector from the drive's serial out to a monitor. Audio is generated using the stepper motor.
I've been trying to find a reference to the board rework removing the high speed serial capability. I heard about it originally in a video or podcast and I'm going to do some digging to find that. To correct the record, though, the board rework story references the C64 motherboard and not the 1541 board.
The 1541 was slow also because of the firmware. There was this kit that I bought sometime in the 80s which, if memory serves, consisted of EPROMs and a small board to be swapped into the C64 and the disk drive in place of their original firmware, then a parallel cable to connect the drive to the C64 via the user port. The firmware also added a much more advanced BASIC interpreter and some utilities. Curiously, by using the parallel cable disk operations became dramatically faster than with the original DIN connector as expected, but if I removed the parallel cable say because I needed the user port, it continued to work, clearly not at the same speed, but still a lot faster than when using the original ROM, so there probably was some room for optimization in the original firmware too. Unfortunately I can't remember the name of that kit, it was one of the many "turbo" this or that on the market at that time, and by today standards looked definitely homemade.
Some of the modern clones of the C64 use JIffyDOS built into the Kernel for faster loading from 1541 drives. The 1541 drive has a 6502 CPU and built in DOS (Commodore DOS not MS-DOS) firmware. It is like getting a whole different computer in the floppy drive which is why it was so expensive.
Believe me, it was very hard to make a slower disk system than the C64 had with the 1541 even back then, and even compared to older hardware. Others in the thread already elaborated why it came to that: A sequence of accidents led to the bus being bitbanged in a terrible way.
"the KERNAL implemented a device-independent I/O API not entirely dissimilar from that of Unix or Plan-9, which nobody actually exploited, as far as is publicly known. Whereas one could reasonably argue that 'everything is a file' in these latter systems, others could easily claim that 'everything is a GPIB-device' in the former."
The TI-99/4A had a similar feature in its firmware. Cartridges could install drivers for devices that appeared to BASIC as file names. For example, if you plug in the Terminal Emulator II cartridge (which had a screen reader feature using the TI Speech Synthesizer add-on) and go to BASIC, you could say OPEN #1:"SPEECH",OUTPUT and get a file handle. Writing to the file handle would cause the computer to speak the text that was written. There was another device, ALPHON, that would cause the computer to speak coded allophones.
I love this, but it's kinda the wrong direction as C64 BASIC had no instructions for gfx and sound.. it was all through pokes. I liked using Simon's Basic to get GFX on my C64 back in the day, but until I had it, I highly envied the Apple 2 and Atari BASIC commands!
This is basically why there are all these Commodore firmware ports - because the kernal doesn't provide all that much and the BASIC has no substantial hardware dependencies.
That's a great point, BASIC 2.0 has very few useful commands for graphics and sound, but these could be added, tailored to the particular platform of a given port. Add a means of "compiling", or exporting, and you get a nice tool for creating NES games easily.
it would be a coooool idea to make an in-line basic compiler... I've stepped through the parsing of BASIC and it takes soooooooo long. e.g. just finding the instruction for say, MID$ takes zillions of cycles. But the actual command is quite simple. So just keeping track of the parsing would make it sooo much better. There are lots of other things to do as well.... but overall I think TRSI has an even better appraoch... you ahve to write Pascal, but you can target C64 hardware quite effiently!
As a Franklin Ace 1000 owner (Apple Clone) I can say that there were no commands for sounds and the graphics were rudimentary, draw a point or draw a line or draw a pretty slow vector shape.
IIUC that's because Franklin cloned the hardware successfully, but couldn't clone the BASIC. But I think you could still run Apple's BASIC from a disk. Do you still have it?
Wow I had no idea there was a keyboard and BASIC ROM for the Famicom: https://en.wikipedia.org/wiki/Family_BASIC It's a shame this never got released for the NES in the USA. I would have had a lot more fun with this instead of the silly Rob robot.
What fun. I was an Atari guy but I could get into something like the Apple II firmware running on something from the era with more interesting graphics and sound hardware.
Thanks! I’ve never worked on SNES ROMs before, but its CPU is backwards compatible, and graphics are probably similar enough.
The main problem is that there was never a keyboard for the SNES. You’d need to implement an on-screen keyboard operated by the controllers or SNES mouse.
