1541 Emulator

From VoidWarranties - Hackerspace Antwerp, Belgium
(Difference between revisions)
Jump to: navigation, search
Line 21: Line 21:
 
* Generally, the slower, the better - timings to the 1541 drive are way better this way. But do not go below 33Mhz, because then the timings will be incorrect too.
 
* Generally, the slower, the better - timings to the 1541 drive are way better this way. But do not go below 33Mhz, because then the timings will be incorrect too.
  
= Project log =
+
= Software implementation =
 +
Because my testing machine has a 500GB SATA HDD, with EXT3 and NTFS partitions, installing DOS is problematic. USB booting with DOS should work, but memory extenders (HIMEM.SYS and EMM386) are conflicting most of the time with the routines which take care of USB support, resulting 99% of the time in a kernel panic, and in 60% of the time in data loss.
 +
 
 +
That's the reason why I've begun stuffing the data into a 3.5" floppy disk - those drives/disks are still common/usable, and they are easier than CD's/pen drives for random access.
 +
The problem I ran soon into, was the capacity of 1.44MB. It should be possible to reformat it to another size (up to 1.9MB if I recall correctly), but I chose for compression techniques because they're much more stable. I created a modular system which allows you to easily extend the DOS disks, and if the disks are formatted into a bigger size, maybe I can put some extra drivers in it.
 +
 
 +
== boot sequence ==
 +
# DOS kernel is loaded, config.sys is parsed
 +
# core drivers (HIMEM.SYS only atm) are loaded
 +
# DPMI extender is loaded so we can use more recent toolchains.
 +
# plugin system is initialized
 +
# plugins are loaded
 +
 
 +
== Plugin architecture ==
 +
Plugins are simple ZIP files which are extracted using PKUNZIP to a RAM drive. To illustrate the structure of a plug in, here's how it is loaded:
 +
 
 +
# PLUGNAME.ZIP is extracted to the RAM drive. It contains a directory PLUGNAME.
 +
# RAMDRIVE:\PLUGNAME\LOAD.BAT is executed to alter environment variables/load device drivers in RAM.
 +
 
 +
Also, the floppy copies itself to a RAM disk using the plug in management system, so you can safely insert another floppy without the need to swap them each time you return to the shell.
 +
 
 +
== Possible improvements ==
 +
* Download packages from the internet to improve loading times, and to make room available for more network drivers. (possible, manageable, unimplemented atm)
 +
* Mount NFS/CIFS share to drive letter for easier D64/data access (possible, but not manageable do to space restrictions)
 +
* Make a BASIC extender for the C64 to make it easier to load new floppies without the need to restart the simulator software each time. (possible, moderate, currently implementing)

Revision as of 12:34, 5 September 2011


1541 Emulator
What:
Remove the need for working 1541 drive/floppies
1541emulogo.png
Participants:
Yvanj
Category:
Coding
Locations:
Den Bunker


Contents

Requirements

Software

Hardware

Software implementation

Because my testing machine has a 500GB SATA HDD, with EXT3 and NTFS partitions, installing DOS is problematic. USB booting with DOS should work, but memory extenders (HIMEM.SYS and EMM386) are conflicting most of the time with the routines which take care of USB support, resulting 99% of the time in a kernel panic, and in 60% of the time in data loss.

That's the reason why I've begun stuffing the data into a 3.5" floppy disk - those drives/disks are still common/usable, and they are easier than CD's/pen drives for random access. The problem I ran soon into, was the capacity of 1.44MB. It should be possible to reformat it to another size (up to 1.9MB if I recall correctly), but I chose for compression techniques because they're much more stable. I created a modular system which allows you to easily extend the DOS disks, and if the disks are formatted into a bigger size, maybe I can put some extra drivers in it.

boot sequence

  1. DOS kernel is loaded, config.sys is parsed
  2. core drivers (HIMEM.SYS only atm) are loaded
  3. DPMI extender is loaded so we can use more recent toolchains.
  4. plugin system is initialized
  5. plugins are loaded

Plugin architecture

Plugins are simple ZIP files which are extracted using PKUNZIP to a RAM drive. To illustrate the structure of a plug in, here's how it is loaded:

  1. PLUGNAME.ZIP is extracted to the RAM drive. It contains a directory PLUGNAME.
  2. RAMDRIVE:\PLUGNAME\LOAD.BAT is executed to alter environment variables/load device drivers in RAM.

Also, the floppy copies itself to a RAM disk using the plug in management system, so you can safely insert another floppy without the need to swap them each time you return to the shell.

Possible improvements

Personal tools
Namespaces
Variants
Actions
Navigation
Toolbox
Content Creation
Belgian Spaces