retrohackers.com
http://retrohackers.com/

ROM hacking with restrictions: what would YOU add?
http://retrohackers.com/viewtopic.php?f=8&t=667		 Page 1 of 1
Author:  gsteemso [ Sun Aug 30, 2015 10:32 am ]
Post subject:  ROM hacking with restrictions: what would YOU add?
I already have a thread about this on the replacement for The Forum that Vanished, but I named it poorly and I suspect that many of those who might have been interested in posting to it didn’t even look at it. Basically, I am motivated to devise an improved ROMset for my Commodore 128s. Things I have already determined that it should contain are:

  • JiffyDOS, with the known bugs in the flat-128 JiffyDOS ROMs squashed. I am told the fix involves copying from the few differing areas in the 128D JD ROMs, which leads me to wonder—apart from the physical form factor, does there, strictly speaking, NEED to be any difference at all between the two ROMsets? (Note: I am aware that JiffyDOS is a copyrighted product. All of this is based on the idea that I would be modifying a single-user-licensed ROM image for personal use, and not for distribution or resale, though I would of course make as many of the enormous patches required to turn JiffyDOS into this beast available for free download as legally permissible. Obviously a lot would depend on the people who wrote the other things I mention below.)
  • Hydrophilic’s BASIC 7.80, which is pretty much the same as BASIC 7 but allows the drawing commands to be used on the 80-column screen. This is somewhat like the origin story for BASIC 8, except BASIC 7.80 doesn’t introduce any incompatibilities with stock BASIC 7 like BASIC 8 does (and as it is a ROM hack, you don’t need to load anything from disk). Hydrophilic has stated that he made the BASIC 7.80 binary freely available with the intent that people use it, so at least there aren’t licensing issues there.
  • A machine language monitor that is full-featured, assists the programmer, and is actually useful, including at a minimum the ability to assemble and disassemble 8502 and Z80 code in memory, perhaps even with proper symbols for system locations and ROM vectors if the system has autobooted successfully and a properly formatted debugging-symbol database is present on the boot disk. This would likely need quite a bit of research and, given the likely space requirements, possibly even a complex ROM with multiple pages overlying the same address range, like certain advanced game cartridges are known to do.
  • Improvements to the boot process, such as:
    • Automatically detecting things like the amount of VDC RAM installed, whether a second SID is installed and if so at what address, the true size of any REU present, the number of internal RAM banks actually present... you get the idea. All of these things involve hard-coded constants scattered throughout the stock ROMs, or memory locations which are initialized with a hard-coded constant value regardless of its accuracy.
    • Improvements to the autoboot functionality. As my background is equally split between classic Macs and 8-bit Commodores, most of these are inspired by the boot drive selector found in Macs of the last 15 years or so:
      • Skip autoboot if a specific key or key combination is held down. My first instinct is to choose Shift for the key (any of Left Shift, Right Shift, or since it is electrically the same as Left Shift, Shift Lock would work, so I guess that would technically be "keys"). If you would use a different held keystroke for this, what would it be and why? (Note: In the past when this has come up, several people have posted that they would disable autoboot by default, perhaps instead requiring a key to be held to trigger it, if it absolutely has to be made possible at all. Trouble is, that only works if your default OS is plain BASIC. For anything else you want it to Just Work without requiring the user to nurse the boot process along. If simply turning the wretched machine on in the morning requires user intervention, it’s not much of an improvement over making them manually issue a BOOT command at the BASIC 7 prompt, is it? I don’t know about you, but the fact that DOS/Windows machines used to require such struck me as absurd even in the 1980s.)
      • Bring up a little menu of some sort listing the available boot devices when a different key or key combination is held down while autoboot would otherwise take place. My automatic reflex is to choose Alt for this, simply because you activate the same functionality on a Mac by holding down Option. Populating this menu would allow early detection of all Fast Serial devices attached to the system, too. In addition to allowing the user to choose a disk other than the one in (unit 8, drive 0) from which to load a boot sector, there would be an option for advanced users which when set would drop the user into the shiny and improved machine language monitor described above, prior to executing whatever boot sector is found and loaded; this would make it far easier to debug the boot process.
  • Fix things that are documented to work but don’t quite hold up when stressed, like the Kernal routine which tells you how many characters fit on a line. The VDC is highly configurable, but when it is active, I understand that this routine will blindly return 80 no matter what the truth of the matter is. I also ought to look up how this function is documented to interact with the text windowing functionality of the screen editor. Is it supposed to reflect the monitor limits, or the current text area's limits?
  • Tangentially related to the foregoing, the KEY function can only be used to examine or change 8 of the ten function key definitions in memory. Technically, the HELP and RUN keys are implemented as part of the function key system, but you can’t view or change them accordingly.
  • Since we’re doing a switchable ROMset based upon and (from the end user’s perspective) working the same way as JiffyDOS, we can make room for a lot of this stuff by ditching functionality that is of little use in a modern setting, such as tape routines and the appallingly slow stock RS-232 emulation. They’re still available if you switch to the stock ROM image.
  • Related to that last one, faster serial I/O might be nice for those who still use it. A friend of mine who goes by AgentFriday has made a 38.4 kb/s routine for stock C64s, and I am quite sure that a 128 could do better than that, especially at 2 MHz.

None of the foregoing is especially contentious as far as compatibility is concerned, though I admit the same cannot be said of the potential licensing issues. Alas, other additions and amendments which might be made to the ROMs are more problematic from a compatibility perspective.

For example, it is entirely feasible to extend the BASIC INPUT statement to be more useful and less messy, such as restricting it to a certain area on the screen (prompt goes here, user typing goes here and scrolls sideways up to the limit you specify instead of overflowing its area, error messages go here) instead of treating the display as an endless roll of printer paper that can’t be scrolled back, which I always found resulted in my screen contents being scrolled out of existence whenever there was an error in my input. Compatibility is maintained by placing all extra parameters between the PROMPT string and its terminal semicolon; should they be absent, the stock behaviour is expressed.

It is even more desirable to add functionality that Commodore was kind of boneheaded for not including in the first place, such as the necessary Kernal and BASIC support to use an REU as a RAM drive, addressing it as a pseudo-serial device just like the keyboard, tape, RS-232, and screen.

(An aside: While any device number not already known to be used for something else is acceptable for this purpose — which basically means you can’t use 0-3 and it is very unwise to use 4, 5, or 8-11 — I personally feel that it should be a single-digit number for ease of typing, and 7 is already in use by Brandon Bogle’s excellent Flyer device, which leaves 6. In theory, as far as Commodore was concerned, all four of device numbers 4-7 are normally used by printers, but in these nearly-paperless times, it seems very unlikely to me that anyone would have more than two printers hooked up at once to the same Commodore. Heck, if you’re using a Centronics adapter to hook up a PC-compatible printer, its device number is likely to be much higher than that anyway.)

Other BASIC extensions that have been suggested include FETCH and STASH analogues for VDC RAM, and AgentFriday has one for C64 BASIC 2.0 called modBASIC that allows local variables and improved parameter passing syntax. If I were not already buried deep under a heap of retrocomputing projects I have been Not Getting Done, I would dearly love to modify that for BASIC 7 (or 7.80; pretty much the same thing). What else would you add, and why? Assume that your only constraints are: (1) it has to be tangibly useful or helpful, and (2) it cannot break existing software.
Author:  RaveGuru [ Fri Sep 04, 2015 12:47 pm ]
Post subject:  Re: ROM hacking with restrictions: what would YOU add?
Very interesting ideas. I had some similar ideas for C64 but using a cartridge, such as RR.
I hope anyone who's a bit C128 literate will be inclined to help out :)
Author:  gsteemso [ Sat Sep 19, 2015 8:51 am ]
Post subject:  Re: ROM hacking with restrictions: what would YOU add?
I like the cartridge idea, but on the other hand, what do you do if you want to use a different cart at the same time? (or three others if you have a cart port expander!) I'm beginning to think that a function ROM might be the smartest way to go about it. It could easily occupy a slot in the Megabit adapter, for example.
Author:  RaveGuru [ Thu Oct 01, 2015 6:02 am ]
Post subject:  Re: ROM hacking with restrictions: what would YOU add?
You're right, a dedicated ROM would be more flexible, provided it can be a Flash ROM so that it can be updated/reprogrammed by software. My idea of a modular ROM for RR is found further down this sub-forum. A bit dated but perhaps time for a revisit :)

viewtopic.php?f=8&t=136
Page 1 of 1 All times are UTC + 1 hour [ DST ]
Powered by phpBB® Forum Software © phpBB Group
https://www.phpbb.com/