• Please review our updated Terms and Rules here

Indespensible Hardware/Software

Postal Patron

Member
Joined
Oct 31, 2003
Messages
32
Once I picked up a C64, 1541 disk driver/printer combo at Goodwill for $10 and a black cartridge was stuck in the 64. Lo and behold it was a EPYX Fastload Cartridge. Did some searches online for some docs and it is a great add on! IMO the Commodore OS by the time of the early 80s sucked, since most people did not want to deal with low level disk commands that the Commodore had, which I think was similar to the Pet in the late 70s. Well, Commodore did not evolve its OS and EPYX came up with a great fix which greatly enhanced the workability of the disk.
 
If by OS you mean the Basic frontend, it was improved in Basic 3.5 and 7 as used in C16, Plus/4 respectively C128. The computer kernel part may only have contained routines to load and save programs, and the rest of the backend was performed through sending commands directly to the drive. Unlike many other 8-bit computers, the 15x1 series has their own CPU and was called an "intelligent" peripheral which can do things on its own, so writing a frontend wedge should be fairly easy.

But yes, Epyx Fastload and later cartridges like Expert Cartridge, The Final Cartridge 1-3, Action Replay 3-6 extended the life cycle of the C64 by some. Actually, the reason why the freezer function in many of these cartridges is working is because the C64 is compatible with a somewhat failed but rare games console, UltiMAX which used a different memory map and the freezer utilizes this map, without going too technical.
 
Wasn't the C64 built as a game console and then turned into a computer instead (hence the great ability for games)?
 
I think you may be thinking of the vic 20.

from what i know...

The vic chip was originally made for a video game machine, but it never materialized, and commodore used the chip and along with the 6502 cpu, built a funky computer

the commodore 64 was designed as a computer right from the get go.

chris
 
64

64

Wow, I didn't know they had additional cartridges in addition to the Fast Load. I'll have to look those up.

While it is nice in ways to have intelligent peripherals, it is advisable to have DOS in RAM like the TRS 80 Model I/III/IV for updates. These TRS 80s had some great DOSs, unlick the Commodore which was locked in with your hardware.
 
Re: 64

Re: 64

Postal Patron said:
Wow, I didn't know they had additional cartridges in addition to the Fast Load. I'll have to look those up.

While it is nice in ways to have intelligent peripherals, it is advisable to have DOS in RAM like the TRS 80 Model I/III/IV for updates. These TRS 80s had some great DOSs, unlick the Commodore which was locked in with your hardware.

DOS in ram takes up valuable ram space needed for programming. Commodore used ROM and could suplement that with addon cartridges as needed.
 
I'm not sure if loadable DOSes mainly update front or back end when they come in new versions. Without the ROM part in the drive, I suppose the computer would have to tell the drive for each track where to go next, handle validate, format, load, save etc.

When it comes to video game, I think Commodore designed the video chip in the VIC-20 somewhere in the mid/late 70ties, didn't find any buyer and finally built a computer of their own. The C64 and UltiMAX games console (both Commodore products) were launched more or less in parallel, but only one took off so to speak. The fact that we saw C64GS video game in the early 1990's is another story, best not mentioned.
 
Re: 64

Re: 64

Unknown_K said:
DOS in ram takes up valuable ram space needed for programming. Commodore used ROM and could suplement that with addon cartridges as needed.

I think although there could be some optimal solutions using ROM on a peripheral, in actual implementation in the early 80s, I think the DOS in RAM won out. Commodore had a workable DOS on the PET, but did not update the commands with later machines (64, 128). Whereas TRSDOS 1.3 was horrific, it was changeable and upgradeable, to where the last versions of TRSDOS were acceptable and third partiy DOSs were superior (MultiDOS, LDOS, etc).

a 'load "*",8,1" is unacceptable for me, a DIR 0 is better.

As far as my previous experiments, there is no "BACKUP 0 1" or similar multidisk copy commands for a Commodore. Yes, there may be a BASIC program which does this but why? If Commodore uses intelligent peripherals, why the copy programs when a solitary command will do?
 
You mean LOAD"$",8 to get a directory. Yes, maybe it is cumbersome to use and even worse to remove files, OPEN1,8,15 : PRINT#1,"S:FILE" : CLOSE1. Newer Basics like 3.5 and upwards had DIRECTORY and SCRATCH, and since the Commodore machines doesn't boot into a shell like many others, the Basic is somehow the DOS frontend.

I don't know how much of a DIR or DEL command has to worked out by the computer on other systems, but in this case I suppose it was enough to send away a few bytes and wait for the data to come back.

I believe there is a copy/backup command in Commodore DOS, but it only works for rare dual drives (i.e. two units on the same device). To copy between two different drives or even to another disk in the same unit, you need a copy program that loads into memory and then saves to disk. Remember that for the advanced commands, the frontend in Basic only forwards the strings you give directly to the drive.

You could have the same argument about missing commands to handle graphics and sound, which is even worse as most of those functions have to be handled by lots of POKEs into the memory. I would gladly have accepted the OPEN-PRINT#-CLOSE idea:

10 OPEN2,grd,1:pRINT#2,"C" : REM open graphics device in 320x200
15 OPEN3,spd,0:pRINT#3,"D:128": REM open sprite device for sprite #0 pointing to sprite at $2000
17 PRINT #3,"X:1" : REM expand sprite in X direction
20 PRINT#2,"L:0,0,319,199" : REM draw line from top to bottom
22 FOR X=0 TO 319 : Y=100+100*SIN(X*1.125)
25 PRINT#3,"P:";X;",";Y : NEXT X : REM position sprite at X,Y
30 CLOSE 3 : CLOSE 2

Now when I think about it, maybe a different Kernel ROM plus a Basic extention ROM could generate something like that, but on the other hand it is easier and more natural to add totally new Basic commands than extend the existing ones.
 
Yes, maybe it is cumbersome to use and even worse to remove files, OPEN1,8,15 : PRINT#1,"S:FILE" : CLOSE1.

I was wondering if someone would mention what a pain it is to delete files in CMB basic 2.0 :)

Luckily, for the vic 20, if you have the programmer's aid cartdrige, you can assign the function keys to do things like ' load"*",8 ' and most of the scratch function.

i think using the cartdridge with its new commands that it gives, behaves very close to CBM basic 3.5 ?

chris
 
I don't know any VIC-20 Basic extention which adds unique disk drive commands. Yes, the PA and SE add programming and graphics commands and the wedge program on 1541 disk adds a simpler wedge, so you can do >$ or >S:FILE (or if it is @$, I can't remember). Many of the C64 cartridges has a wedge built in, so even with Action Replay you don't get DIR or DEL, but $ and @S directly from Basic.

And @B and @C which are special commands for whole disk backup and file copy, but those are handled by the cartridge, not by the DOS or disk drive. Inside the monitor you even have @BR for readining individual blocks from disk into computer memory, but that is also thanks to the 32K expansion ROM of the cartridge (as well as the freezer, turbo load, extra commands etc etc).
 
There are some of us, (not me) like Leif (schema) who have access to eprom burners, and can make their own carts.

would be nice then to make an enhanced basic cart. for the vic.
 
Fastload was a nice add-on to the DOS, but it wasn't 100% compatable with comercial software. Lots of games wouldn't work with it(unless you had a cracked version), and AFAIR most of the copy programs(Fast Hack'Em for instance) would go nuts while that cart was running.

Speaking of Fast Hack'em, one of the later versions supported something I call "Blind Copying"...you hooked up 2 drives(8 and 9), set them to an auto-copy, and you could disconnect the drives from the computer. The drives could sense when a new disk was inserted, and it would copy when both disks were in. Talk about handy! Try doing something like that today! :wink:
 
Back
Top