Skip to content

Archive

Category: Commodore

www.mediapalatset.com gave me a mystery cart which, after some investigation, turned out to be a floppyspeeder kernal cartridge. He also had a 1540 drive with matching speeder-ROM to accompany the the cart. Thanks ! 🙂

 

The internal Kernal-ROM can be replaced with an external Kernal-ROM cartridge. This cartridge design is a different one than the standard cartridges mentioned at Making a C64 Cartridge and should not be mixed up. The only common thing is area $E000-$FFFF, which is used by Kernal-ROM and Ultimax-mode (RAM at $E000-$FFFF needs also to be taken into consideration).

You can not use plain Ultimax-mode to create an Kernal-ROM cartridge since Ultimax will bank out all memory between $1000-$7FFF and $A000-$CFFF making it rather unusable. A way to enter Ultimax-mode only when accessing (Kernal-ROM) area $E000-FFFF is needed.

To determine if adressing $E000-$FFFF should be ROM or RAM is done by setting HIRAM bit in $01 CPU I/O-register. Having an external ROM at $E000-$FFFF in the cartridgeport causes problems since the cartridgeport HIRAM-signal is used for accessing the BASIC-ROM at $A000-$BFFF. There is no equivivalent HIRAM-signal for $E000-$FFFF in the cartridgeport.

The simple solution is having some extra logic and attach a wire from the cartridge to the HIRAM-signal inside the computer, therefore kernal replacement carts most often come with a cable and a clip for this purpose. An example of this is the V-DOS / EXOS V3 (REX9805) cartridge. You can leave the wire disconnected but access to RAM at $E000-FFFF is not available which limits the functionality a lot (unless running plain basic).

EasyFlash3 and 1541Ultimate use a more elegant solution without a need of an extra wire, Skoe has written an excellent document in the subject: How to build a real Kernal Cartridge.

 

Turbo DOS V3
The cartridge had a sticker on it saying “Turbo DOS V3”. It also had a reset-button and a switch to be able to change eprom banks for (inter)national kernal. The wire was connected to the solder dot left of the 74LS30 IC. Delikatess-data was a shop located in Gothenburg, also selling Dolphin DOS at the time. I desoldered all components and scanned the PCB for documentation purposes.

 


 
 

HIRAM-Signal and the wire
The cartridge needs a wire connected to the HIRAM-signal inside the computer which is located at pin 28 on the CPU, you can study the schematics for more convenient locations of the HIRAM-signal.

Clip connected to pin 28 on the CPU (C64E / Assy 250469).

 

OpenC64KernalCart by Sukkopera
I was in contact with Sukkopera asking if he interested in doing a PCB for the kernal cartridge. He did a great job and refined the design. You can now have 8 different kernals on the external cartridge selectable by jumpers.


OpenC64KernalCart holding 8 different kernals. The HIRAM-signal should be connected to the yellow pin-header.

 

Track-Master is a device which displays current track (and halftrack) position of the R/W Head.

I have no documentation nor a manual for this device and very little information is available, therefor I will try to summarize a bit from the adverts found from around 1985-86.

There are three versions mentioned in the adverts, Track-Master(external), Track-Master plus(external with audio alert) and Track-Master GT (internal version of the plus).

1541,1571 and SX-64 are supported and “soon” available for Amiga and non-commodore drives.

* Digital display showing track, half and fat tracks 1-40.
* Control switch settings displayed on the LED.
* Audible alert when writing to the disk or when track sync marks are not normal.
* Control swithes allow you to:
   Set drive unit to 8 or 9.
   Write protect disks electrically.
   Bypass write protect (use both sides of a disk without notching).

Track-Master uses the stepper movement to display current track/halftrack and works with all sort of loaders. It has no way of knowing the exact position of the R/W head and resets to track 18 when drive is reset. This is a close assumption as the drive always start reading track 18 for a file or directory in normal load operation, which is perfectly fine. If you move the R/W head manually a few tracks it will assume the head was never moved and show wrong track number until next reset. Sometimes it starts off with track 19 when it should be 18, a reset of the drive fixes this problem.

 

 


Control Switches (assumed operation by testing):
8/9 : Device number. A LED dot is lit when device 9 is selected.
W/T : Audible alert when (W)riting to disk or when (T)rack sync is not normal.
N/P : (N)ormal / Write (P)rotection. Extra LED segment lit when active.
N/B : (N)ormal / (B)ypass write protect tab. LED display blinking when in bypass mode.

 


All ICs and transistors have their markings grinded off to prevent duplication of the board.

 

 

 


Signed by the previous owner, “Mitch ESI. Rush Rules!” 🙂

 


Drive PCB wiring.


PCB #251830
Blue     Capacitor C16 + (5V)
Green    Capacitor C16 - (GND)
Black    UA1 Pin 5 (WPS - Write Protect Sensor)
White    UC1 Pin 10 (Step)
Gray     UC1 Pin 12 (Step)
Brown    UC1 Pin 37 (Sync)
Purple   UC1 Pin 36 (Mode;Read/Write)
Red      UC2 Pin 19 (Mode;Read/Write). Note:Lift up pin 19 from the socket.
Orange   Device number pad, cut jumper and solder wire.
Yellow   Capacitor C46 + (Reset)
UC1      Add 10K pull-up resistor between Pin 1 (VCC) and Pin 36.

 


First part is fast formatting a disk, and second is loading a game where it switches to a fastloader after a while. The video does not quite do justice for the 7-segment LED display as it is more distinct in reality.

 
Advertisements
Compute Gazette Issue 24 (1985 Jun) Page 128
Compute Gazette Issue 35 (1986 May) Page 122
Compute Gazette Issue 39 (1986 Sep) Page 124

 

FB (FileBrowser) v2.0+ is a standalone version of the filebrowser(FB) used in JaffyDOS v1.3, now supporting over 3200 directory entries.


CRSR UP    = Up one position.
CRSR DOWN  = Down one position.
CRSR LEFT  = Up 10 positions.
CRSR RIGHT = Down 10 positions.
F1         = Go to First entry in the list.
F2         = Refresh.
F3         = Go to Last entry in the list.
F7         = Quit.
RETURN     = Load & Run / Enter dir / Mount image or swaplist.
INST/DEL   = Exit dir / Unmount image.

 

 


 
Option below is for advanced users only.
 

Colors can be customized by modifying values in the beginning of the code. Unfortunately it is not an userfriendly operation, but I thought I’d mention it for those who want to change them. You need to launch your favourite HEX-editor to do the changes.
 


$080e   0xA9,0x9A        lda #$9A      ;Diskname (PETSCII code)
$0810   0x8D,0x72,0x08   sta $0872
$0813   0xA9,0x0E        lda #$0E      ;Selection row (COLOR code $00-$0F)
$0815   0x8D,0x26,0x09   sta $0926
$0818   0xA9,0x0E        lda #$0E      ;Charcolor (COLOR code $00-$0F)
$081a   0x8D,0x86,0x02   sta $0286

Adresses above are relative to $0801 as basic startadress (excluding the two bytes for loadingaddress).

 

         COLOR  PETSCII
Black     $00     $90
White     $01     $05
Red       $02     $1C
Cyan      $03     $9F
Purple    $04     $9C
Green     $05     $1E
Blue      $06     $1F
Yellow    $07     $9E
Orange    $08     $81
Brown     $09     $95
Pink      $0A     $96
Dark Grey $0B     $97
Grey      $0C     $98
Lt.Green  $0D     $99
Lt.Blue   $0E     $9A
Lt.Grey   $0F     $9B
Color lookup table for COLOR and PETSCII values.

 

 

JaffyDOS is a custom kernal for the C64/SX64 with enhancements for SD2IEC.
Filebrowser and Kernal modifications by: jani@worldofjani.com

 
2019-04. Version 1.3
* Fixed a bug when using FOR in basic direct mode.
* Free memory shown correctly if cartridge is inserted.
* Startup-message can be customized with the patcher.
* Optional SWE/FIN keyboard layout available in patcher.
* FB adjusted to work with pi1541.
* Default F-key assignment adjusted to work with pi1541.
JaffyDOS was initally written for SD2IEC devices but due to many requests I adjusted a few things for pi1541 users. Currently there are some differences in SD2IEC and pi1541 and therefore full functionality can not be guaranteed on a pi1541 device.
 
2017-07. Version 1.2 (Upgrade to v1.3 is recommended)
* Includes saveroutine fix from v1.1.
* Filecopy works again with files up to 201 blocks.
 
2017-07. Version 1.1 (Not a public release)
* Quickfix for those who experienced problems.
* Saveroutine fixed. Some games bank out basic before saving and could cause the save to fail (e.g. highscore).
* Filecopy temporarily limited to 152 blocks because of the savefix.
 
2017-04. Version 1.0 (Obsolete, don’t use)
* Initial release.

 

Features:
* Jiffydos protocol and DOS wedge.
* Customizable color scheme.
* Customizable F-Key assignments.
* Startup-message can be customized.
* Built in filebrowser(FB) supporting 590 entries.
* Built in file copier.
* md64/md71/md81 to make a d64/d71/d81 image.
* CRSR moves to beginning of the line when executing F-Key.
* When loading a file, the start- and end address are displayed.

Tape- and RS232 support are not available.

Use the patcher to create JaffyDOS ROM. You must provide an original Jiffydos ROM and be a licensed Jiffydos user to use JaffyDOS in your system. You can purchase Jiffydos from http://store.go4retro.com/

 

Thanks to Tom-Cat, Erhan and Lemming for feedback and extensive testing. Your help made it possible! 🙂
Additional testing for version 1.1/1.2 done by Snear and Marty/Radwar.
Version 1.3 testing by Tom-Cat, ozotheclown, Jonny Hylander and Björn Hutmacher.

 

 
Disclaimer:
No warranties whatsoever, use it at your own risk 🙂

 


 

JAFFYDOS PATCHER

 


 


Enter the filename of the original Jiffydos ROM.

 

Create a personal color scheme or select one of the predefined schemes.

 

Select between C-64 or SX-64 default startup-message or customize it.

 

Default(standard) and optional SWE/FIN keyb layout. For any other
layout, select default and patch the file manually afterwards.

 

The F-key commands can be re-assigned.

 
 


 

JAFFYDOS INSTRUCTIONS

 


 

Default F-key assignments: (customizable with the patcher)
F1 = @"$"       DIR<CR>
F3 = %          LOAD and RUN<CR>
F5 = @ "CD:     CD directory/mount diskimage<CR>
F7 = @"CD:<-"   CD parent dir<CR>
F2 = /          LOAD<CR>
F4 = @ "XS:     Mount swaplist<CR>
F6 = @  "S:     Scratch file
F8 = @FB:       Start FileBrowser<CR>

<CR> Executes the command automatically after pressing the F-Key.

 

 

DOSWedge Commands:
@                   Read disk drive error channel
@$                  Display disk directory
@#device            Set device number
@C:newfile=file     Copy a file on the same diskette
@I                  Initialize disk drive
@N:diskname,ID      Format (NEW) disk
@N:diskname         Short NEW
@Q                  Disable JaffyDOS
@R:newname=oldname  Rename file
@S:file             Scratch file
@UJ                 Reset disk drive
@V                  Validate disk
/filename           LOAD program
£filename           LOAD program
%filename           LOAD and RUN program
↑filename           Load and RUN program
←filename           Save program
'filename           Verify program

<SHIFT>+<RUN/STOP>  Load & run first program on disk
<CONTROL>+<D>       Default drive toggle
SYS 64000           Re-enable JaffyDOS functionkeys and commands

 

 

New DOSWedge Commands:
&filename               Verify program
$                       Display disk directory
@8                      Set device number to 8
@9                      Set device number to 9
@1x                     Set device number to 1x
@FB                     Start FileBrowser (or @F)
@MD64"filename.d64      Make .d64 image
@MD71"filename.d71      Make .d71 image
@MD81"filename.d81      Make .d81 image

 

 

Make image; D64, D71 or D81:
* Use single quote only in the command.
* Max 16 chars in filename+extension(.D64/.D71/.D81).
* File extension is mandatory.
* You must mount and format the diskimage afterwards.
 

 

SD2IEC Supported commands:
See the SD2IEC readme-file here
JaffyDOS does not require extra quotes in some of the commands.
 

 

Additional commands which are not mentioned here but are referenced in the Jiffydos manual, have been removed to fit the new features in JaffyDOS.
 

 

Filebrowser:
CRSR UP    = Up one position.
CRSR DOWN  = Down one position.
CRSR LEFT  = Up 10 positions.
CRSR RIGHT = Down 10 positions.
F1         = Go to First entry in the list.
F2         = Refresh.
F3         = Go to Last entry in the list.
F7         = Quit.
RETURN     = Load & Run / Enter dir / Mount image or swaplist.
INST/DEL   = Exit dir / Unmount image.
$          = Display "real" dir.
+/-        = Increase/Decrease device number.
CBM C      = Filecopy. Load(copy) file into memory, see below.
CBM V      = Filecopy. Save(paste) file to disk, see below.

* 590 entries allowed in directory.
* Remembers last position when returning from a directory or unmounting an image (one level).
* Files with extension .D64/.D71/.D81/.M2I/.DNP are mounted as disk images using @CD:
* Files with extension .LST are mounted as a swaplist using @XS:
* Character set is changed to uppercase when entering a diskimage.
 

 

Filecopier (for small files, only available in FileBrowser)
1. Hold down the CBM-key and press “C”. Selected file will be loaded into memory.
2. Go to destination location with filebrowser.
3. Hold down the CBM-key and press “V”. File is now saved into current location.

* A file can be copied from/to the SD2IEC filesystem, a mounted image or swaplist, or from/to another device number/type.
* It is not possible to copy(CBM-C) a directory or a disk-image.
* Selecting / copying multiple files is not supported.
* You can not paste(CBM-V) if a file has not been loaded or if the copy phase resulted in an I/O error.
* I/O Errors will be reported.
* Max filesize: 201 blocks. (exceeding the size will cause a crash).
* File can be re-saved(CBM-V) several times at multiple locations.
* You have to re-load a file (CBM-C) if you exit and return to FB.

 


 

The Final Chesscard by TASC was released in 1989 for the Commodore 64/128 and PC. The C64/C128 version plugs into the Expansion(cartridge) slot and the PC version comes with an ISA Card.

The Chesscard forms a stand-alone computer with 32K of ROM, 8K of RAM and an extra CPU running at 5 Mhz. Program software was delivered on disk for the PC and the C64 software is loaded from an additional 32K ROM on the C64/128 cartridge.

 

The Final Chesscard C64/C128

Unfortunately my Chesscard only displayed a black screen with white stripes, so I began to investigate it.

The C64/C128 Chesscard has two 32K ROMs which I dumped with an eprom reader. One ROM contains software for the external CPU(“brom”) and the other has software for the C64(“crom”). The ROM namings can be found in the Chesscard menues.

The C64-ROM consists of two banks, both 16K at $8000-$bfff. The bank is selected by setting $DE00 to $40 or $41. The Chess-ROM is 32K at $8000-$ffff and boots independently with reset vectors pointing to $FF22.

I needed a way to test the ROMs. The same company was involved in making the “Final Cartridge III” which has 16K sized banks and uses $DE00 for bank swapping. I created a TFC3-type cartridge ROM for emulators(.crt) and wedged in code to set $DE00 accordingly. The Final Chesscard now started up in the Vice emulator, displaying a black screen with white stripes.

Now it became much easier to debug. After examining the code, I could see the “black screen with stripes” was waiting for the extra CPU to acknowledge it was running (possibly these two communicate with each other using zeropages $04-$0e). I removed the checks and had the Chesscard running graphically, the chess engine itself was of course not working.


The Final Chesscard in Vice
It is not playable since there is no support for the extra hardware. I had to patch it to bypass the hardware checks.

 

I eventually figured out the extra CPU did not start up properly. I took out my desolder gun and removed the CPU. It was tested OK on another equipment. After desoldering the crystal I noticed that one of the legs was broken, and while at it, I decided to clean up the whole PCB for documentation purposes. You will find scans and pictures of the PCB below.

 

Component list:
74LS04
74LS30
74LS32 x 2
74LS74
74LS174
74LS374 x 2
SRAM = 8Kx8 TC5565/MCM6064
CPU = G65SC02P-4
ROM1/ROM2 = 27256 Eprom
D1-D6 = Diode 1N4148
ZD1 = Zener diode 2V7
C1-C2 = Tantalum 1uF 35V
C3-C6 = Ceramic 0.1uF
C7-C9 = Ceramic 1.0nF
C10 = Ceramic 0.56nF
X1 = Crystal 5Mhz
Resistor 2.2 KOhm x2
Resistor 680 Ohm x2
Resistor 330 Ohm
Reset button

 

Everything back in place and all IC:s socketed.
 


Final mount. The Final Chesscard is now fully functional with english language.

 


 

Final Chess Card – Forum64 Edition
With the information above, Freak at forum64.de reproduced and redesigned the chesscard completely, it fits into a standard cartridge case. Really impressive work !
 

 

You can read about the project at Forum64.de and GitHub.

 


 

 
Downloads:
The Final Chesscard came in two languages; english and german. The language is hardcoded on the ROM and the english ROM has been quite hard to get hold of (until now). There are demo versions available in both languages on disk but those are incompatible with the ROM version.

By studying the code, I managed to make a C64 tool to extract the ROM and Ratuv at Lemon64 kindly run the tool and extracted the english ROM.

Make sure to get the updated german ROM if that is your language preference. Thanks to DDI for the sending. The FCC ROM, brom, 1.0 and 1.5 are not interchangeable for the english version.
 


English C64 ROM : crom 0.9 12-10-89
German C64 ROM : crom 0.9 29-11-89
FCC ROM : brom 1.0 05-10-89


German C64 ROM : crom 1.3 16-07-90
FCC ROM : brom 1.5 22-05-90

 

 
Credits:
Ratuv at Lemon64 for the english ROM.

DDI (http://www.sys64738.net/) for the updated german ROM (crom 1.3 / brom 1.5).

Forum64.de members for the manual, extras and a disk (autoplay, openings, replays etc. available from the File-menu).

 
 

Here are scans of my Commodore Service Bulletins by RCA Service Company.

 

 

 

 

GEORAM is a 512K memory expansion unit made by Berkeley Softworks for use with GEOS. It can also be used for other programs, but is not compatible with Commodore REU. There are several programs that support GEORAM though, for example Maniac Mansion GOLD.

The Shareware PLUS Commodore 64 & 128 Blog has redesigned the GEORAM to fit inside a standard cartridge case and it does not require a heavy duty powersupply like the Commodore REU would. You can find the new GEORAM at The Shareware PLUS Commodore 64 & 128 Blog

 
 


The new GEORAM comes with a box and a manual.

 
 


Just for comparison. The original geoRAM to the left is very bulky and the PCB had to be exposed so it would fit into the C128D. I was always afraid to break something by mistake when handling the geoRAM. The new design is much better.

 
 


Contents of the original geoRAM and the new GEORAM.

 
 

ZoomFloppy does not come with a case so I searched around and found one which was a pretty good fit. I found the case on eBay listed as “Type Z80” with measurements of 119x90x38mm and cost me €7 including shipping. The PCB is fastened with 7mm high standoffs, you need to drill holes into the case to match the holes on the PCB. Here are some pictures of the result.

Spectacular Copy Turbo to Disk, SCT2D, a widely used tool for preserving turbotapes got another update. This time completely rewritten from scratch with support for several fastloaders and a built in head alignment.

You can find the tool at CSDB, http://csdb.dk/release/?id=147196

 
SDT2D Changelog:

v2.0. Written from scratch by SAILOR/TRIAD
* All functionality from earlier versions included.
* Fastsave I/O for 1541/1581/DolphinDos devices.
* Added support for JiffyDos.
* Built-in HeadAlign v1.1 by ENTHUSI/ONSLAUGHT. Press RESTORE during transfer
to restart and/or enter HeadAlign and RESTORE again to exit HeadAlign.
* Safe(slow) saveroutine using CHROUT for mass storage devices.
* Savespeed comparsion of a 180 blocks file (mm:ss):
IDE64 00:08
DolphinDos 00:13
SD2IEC+JiffyDos 00:18
1581 fast I/O 00:19
1541 fast I/O 00:27
SD2IEC 00:54
1581 slow 01:03
1541 slow 02:11

v1.2 by SAILOR of TRIAD
* Fastsave I/O for 1541 drives.

v1.1 by WACKEE of ARISE:
* Automatic replacing of invalid chars (,*?) before save [option].
* Accurate block size calculation.
* Proper handling of 0-byte files.
* Fixed resave on diskerror.
* Rename without space-fill.
* Tapeload with sound.
* Changed default settings.

v1.0 by SAILOR of TRIAD:
* Asks for disk change if file is larger than free blocks on disk.
* Resave option on diskerror.
* Option to rename file.
* Can use other devices than #8.
* Autotransfer mode option.
* Load error detection.

 

 

My friend Xiny6581 at the http://sidpreservation.6581.org/ asked me to take a deeper dive into a tape he had gotten for preservation.

You can read his findings on the tape at:The True Art of Data Archaeology, but we both felt there was more to find out on these tapes.

We came pretty quick to the conclusion the tapes were disk backups saved to a turbotape format. None of the current turbo transfer tools were able to identify the files, nor the format properly.

I made a tool to inspect the raw turbo-data on the tape. The files start with a standard turbo-tape header and the rest of the data is custom turbo-tape. With this information i made a tool which saved the raw data to disk.

 

After the turbo-tape header, a custom header follows with $02a1 bytes of data. The header has checksum(Yellow) and a name(Orange). The name is something you’d type in since it does not reflect the name of the disk. When restoring, the original program probably looked for “a bunch” of $02;s plus a sequence of $09,$08…$01,$00 and everything after those bytes is data.

Four consecutive files on the tape has the same name in the custom header why I came to the conclusion each disk was split into four files.

I was able to determine the size of the header by assuming the first block of data from the tape was from the lower tracks(sectors) of the disk. Therefor the bytes $01,$0a is a track/sector-link(lightblue) and the bytes $a9,$0a,$48,$a9,$00, which translates to LDA #$0A/PHA/LDA#$00, is programdata(lightgreen). This is how the data is structured on a disk.

Now i had found an offset for the disk data. I knew every $0100 bytes after the header corresponds to a sector on the disk. However, this was the easy part. I got pretty fast aware of the fact the sectors were in no logical order. After saving all data out, I had 9 backups of disks giving a total of 683*9(=6147) sectors that had to be puzzled together.

I started reconstructing the directory tracks. Track 18.0 holds the disk name and was found on all backups in the third file at position 0x11c1. It will also link to track 18.01 (hex $12,$01) which is the first block with filenames and track/sector links to the files.

One of the games was Flight Simulator II. Knowing that it is a full disk copy with the same placement of sectors(data) throughout the disk compared to the original game caught my interest. I made a tool which checksummed every block of $0100 bytes from the four files and compared it to every sector on the original disk. When there was a match, I knew which memorypositon in which file corresponded to a track/sector on the disk. After a match, the tool would not check the same sector twice.

I got out a fair amount of matches, not all though, since many sectors were empty and therefor matched multiple sectors. After running the same tool on another disk, Ultima II this time, it returned many identical matches with the first run. I knew i was on the right track(pun intended) and it looked like the layout was same for all disks.

With the result from the checksum runs on a couple of more disks I (roughly) knew the following:
File 1: Tracks 01-08
File 2: Tracks 09-16
File 3: Tracks 17-25
File 4: Tracks 26-35
The sectorlayout was not the same throughout the four files, but I could see a repetitive pattern which filled in some of the blanks after tweaking my tool a bit.

 
With the tables generated, and with the information in them, I wrote out the files to diskimages. Now I had 9 disks, with partially written data to them. I tried loading some files, but they often halted in the middle of loading since it hit an empty(zero-filled) sector telling the drive it is the last sector to load. There is no data written on those sectors either.

This is where I got ideas for another tool, and where I searched for partial matches from other releases found on CSDB. One disk was Summer Games and I knew it has a number of files which matches with the data written (and not yet written) to the diskimage.

My new tool would try to extract a file from the images I built. When it hit the track/sector links $00,$00 (i.e. empty sector) it would store the current track/sector and know which sector(and which track) was missing data. I also had pointed out the corresponding (complete) file and the tool searched/compared where identical data ended. From that offset it matched ($0100-2) of data from the four files which had not yet been written to disk.

When the data was identical, I got a visual feedback to confirm if the (next) track/sector link was within reasonable limits. I was able to verify it with the earlier information about which files held which tracks and if the sector links follows the pattern how a file gets written to disk (i.e. 01,11,02,12,03,13,04,14…).

 
With a couple more files from other games, and with my tool, I was able to reconstruct all track/sector data for all the 9 disks :).

 

However, we still don’t know which tool was used for this backup, if you have any information, please let me know.