What the subject says. Has anyone got one of these manuals? I bought the hardware today at the used computer dealer for $7, but after hours of Googling I am no closer to finding out exactly what it is capable of.

I did find out that it doesn’t do descenders â€" I seem to have a knack for accidentally acquiring Commodore printers that lack that functionality, as my other specimen is an MPS-803 â€" and also that it is supposed to be considerably quieter than its predecessor, the 3022. Nice to know but not terribly helpful. :¬)

TIA,
G.

It’s the kind with the “Fat 40” universal 40/80-column motherboard. There is a fellow on one of the PET sites who sells new-old-stock official Commodore-branded 64K RAM upgrades that will work on this model, but they appear to preclude other modifications within the case due to being physically enormous. (I am particularly taken with the idea of the internal IDE modification I’ve heard rumours of, but there are others possible.) Also, I’m not at all sure I could afford to pay for such a beast; with shipping and so on, they are quite expensive by my standards.

Does anyone have any pointers to documentation on using the 100 expansion header pins at the back right of the motherboard? I know from the 8296 documents I’ve examined that 50 of them are just ground-plane pairs, but I lack detailed explanation (and reliable identification) of the 50 actual signal pins. I haven’t even seen a reliable indication of what kind of female connector you would use to plug onto the two 50-pin headers!

Hoping someone’s gone this route before me,
gsteemso

What happened to the descriptive line you used to be able to add to a new thread? I found it very useful for elaborating on whatever I put as the main subject. It was good for humour purposes too -- for example, I made a post whose subject was along the lines of "Unicode Support on GEOS?". Naturally, I had to add a description of "no, really". The subject is still there in the GEOS forum, but the description isn't. I want it back! Any chance of this change, Blacklord?

Kernal ROM replacements are nothing new. Most of us probably have JiffyDOS or a similar fastloader, for example. (Note that a cartridge ROM sorta counts here too.) The trouble is, when you buy one off somebody, you're limited to that one modification unless you're a skilled assembly programmer and can get your merged code into an EPROM somehow.

So, if you could redo the 128's system ROMs using today's codebase, what would you include?

Here are some ideas to start us off:

- JiffyDOS
- a better MONITOR function
- improved 80-column text handling (video-interlace mode for 80x50 work, autosense of whether the 80-column screen is in "fat 40" mode, etc.)
- improved RS-232 routines that work out of the box, so you can simply write your communications program code instead of fighting with stuff that was theoretically already there

If you used an expansion cartridge instead of a Kernal replacement, you could include transparent IEEE-488 handling and Ethernet capability as well. That starts to get into the realm of "dream expansions" like µIEC and SuperCPU though, so we should probably limit ourselves to considering only what can fit in a ROM.

What would you want to include?

I bought a 128 function ROM with this utility in it, but the damn thing didn't come with any instructions for the software. I Googled for almost an hour, but all I could find was some guy who'd sold one a few years ago claiming that the instructions were "easily Googled". Gah. I've written to the eBay store who sold it to me, but who knows when I'll hear back. Help!

I've been giving considerable thought to moving my fanfiction writing over to the C128, in order to reduce the temptation to read other people's fanfiction over the Web instead. For that to happen, I need 3 things.

1) A method of transferring files from the C128 to a modern machine. I've got an elaborate and roundabout kludge in mind involving AppleTalk and a IIgs equipped with a 5-1/4" drive, but if that doesn't pan out there's always uIEC.

2) A usable method of embedding Unicode characters into what I'm writing. Could be tricky without writing my own text editor. I'm seriously considering doing exactly that, which is why this post is here. More below. (As a workaround if this doesn't pan out, I could use mnemonics and have a postprocessor spit out proper Unicode. I already use postprocessors to target various publishing languages, such as HTML or BBCode, so this isn't a big leap.)

3) A way to run the postprocessors (which are written in Perl) on the C128. Basically, a simplified Perl 5.8.x interpreter for the 128. I intend to post elsewhere about this, as it is not specific to GEOS.

So, back to writing a text editor for GEOS. Does anyone know if the GeoWrite source is available? I could probably run something together even if not. (An old post on a Mac newsgroup about how old versions of BBEdit worked internally was very helpful there.) Of course, I will have to track down a copy of GeoProgrammer before I can get anywhere, which in turn relies on me solving the disk-transfer problem in item #1 above. Gah. This isn't a small project, is it...

I also had some questions for the group at large about font and text handling in GEOS. Basically, all text is assumed to be ASCII or some variant thereof for international translations, correct? What is the internal structure of a font? Would I have to rewrite the entire font subsystem of GEOS to handle a typeface with over 255 characters?

I'd given some consideration to introducing a method of embedding Unicode as gaiji (to steal a Japanese term), where some application-specific flag indicates that a character from beyond the current repertoire is to be used. I think that would be a lot easier than full Unicode support, which would probably be impractical on such a small system. I'd still need some way of having internationalized fonts though. Maybe have a series of related font files with different 128-character "slices" of the Unicode repertoire?

Thoughts?

The question recently arose, what expansion options do various Commies have in common?

So far I know of the following [modified 2008/09/06 to account for suggested updates and further research]:

User port:
- none: C16, C116
- type 1: PET/CBM
- type 2: B-series (separate ports for user and RS-232C)
- type 3: VIC-20, C64/SX-64, C128, Plus/4
- no idea: LCD, C65

Cartridge/expansion port, under various names:
type 1: PET/CBM
type 2: B-series (separate ports for cartridge, expansion and co-processor)
type 3: VIC-20
type 4: C64/SX-64, C128
type 5: C16, Plus/4
no idea: C65, C116, LCD

IEEE-488:
yes: PET/CBM, B-series, LCD
no: all others

IEC serial:
yes: C16, VIC-20, C64/SX-64, C116, C128 (fast), Plus/4, LCD
no: PET/CBM, B-series, C65

Tape:
yes: PET/CBM, some early B-series, C16, VIC-20, C64 (except SX-64), C116, C128, Plus/4 (unique socket, mini-DIN)
no: most B-series, SX-64, C65, LCD

Other:
Plus/4 parallel: Plus/4 (via a cartridge)
C65 serial: C65

Further additions and/or corrections, anyone?

In the discussion of "Ethernet over IEC" over in Herdware, the side topic arose of identifying common expansion options between different CBM 8-bit machines. I wanted to start a new topic somewhere to thrash that one out a bit more completely, but there doesn't seem to be any exactly suitable forum on this site. It would fit best in the "Other machines" section, but there's no general-purpose forum there. Can anyone advise me?

Hiya!

Was lusting after various Ethernet adaptors for C64s when I suddenly realized there weren't any for other CBM machines, at least not that I can find.

Making one for a PET shouldn't be that hard IMO, as the IEEE-488 bus is very fast, though I'm unsure how well the CPU could keep up.

The Vic-20, C128, Plus/4, etc. are a little more problematic. If the C64 can keep up with Ethernet I'm sure the others could as well, but developing a new cartridge for each type of machine (and then having to tweak it so it worked with slightly unusual models like the SX-64 or the Commodore LCD) would be ridiculous. If we had something that hooked up via the IEC bus, that would be about as compatible as I can imagine, though it would probably need JiffyDOS or similar to work at all well. (Do the Plus/4 and its brethren even work with IEC? ISTR they came with a different disk drive -- the 1551 or some such. Anyone remember why?)

Another alternative is to dangle something off the tape port, but not all machines came with one and we'd be back to the problem of needing custom Kernal drivers for every Commodore platform. Not really practical IMO.

An IEC-based Ethernet adapter would appear to a stock system as indistinguishable from any other serial device, though it wouldn't be much use without some sort of fastloader. I'd propose JiffyDOS for that as it's already implemented for everything, and offers numerous fringe benefits, such as a wide preinstalled base. (Maurice Randall is not one of those benefits, but happily, alternatives to his fraud service now exist.)

Software to access the device is more problematic, but then, since current devices all run only on the C64 (and would probably offer superior performance on that platform), any implementation would be starting from scratch anyway (stuff written for a C64 functions poorly or not at all on the other platforms I listed above). From that perspective, the proposal sounds quite reasonable to me.

Reactions, please?

If you're like me, you have (1) a TV that only has composite, RF and S-video inputs, and (2) a Commodore video cable that predates S-Video, and thus brings the Luma/Chroma lines out to separate RCA plugs instead of having them unified in a mini-DIN-4. Up until yesterday, I thought the only way to connect the two was to make your own adapter, but it turns out a 6' cable with RCA plugs at one end and a male mini-DIN-4 at the other is available for about eight dollars from a local electronics retailer. Some digging produced this link: http://shop.vetcosurplus.com/catalog/product_info.php?cPath=37_38_44&products_id=132

They have a 12' version too, but I don't see that being too useful unless your Commie and your TV are really far apart.

A couple of F-F gender changers for the RCA plugs and you're all set!

G.

Subject line says it all. I'm in Kenmore and I know a guy near Tacoma, but that's all I've been able to find. Isn't anyone else near here?

The following suggest themselves as obvious:

30-pin SIMMS (the 8-bit-wide kind) are so obsolete as to be essentially free.
Cartridge cases and prototyping boards are less so, but still commonly available on eBay.
REUs are hard to find and expensive to obtain once you do.

There is almost nothing in the Commodore REUs, just RAM chips and some glue-logic chips AFAICT.

So, why not roll my own? The trouble is, I have no idea what I'd need to do to make it compatible with all the existing ones, like the Commodore ones and the SuperCPU's RAMCard and the 1750XL and so on and so forth. What sort of API do they present? Do I need to graft the thing in to the C128 memory map at some certain range of addresses? How does it work?

There are apparently as many implementations of subdirectories as there are drive expansion projects -- LT Kernal, CMD native, VICE native, etc. If I want to fiddle a 1581 to access other sorts of disks than the Commodore-formatted ones, knowing what to present to a Commodore program so it won't choke on subdirectories is vital. Where can I find information on how to program with subdirectories on the most common implementations? Once I have that I can reverse-engineer something.

Hi there everyone.

I have a 1571 (not a 1571-II) that failed during transport (there was no head protector when I moved it across Seattle in my backpack). It powers up normally, and is able to tell when it has a disk in it or not (it fails with the normal 74 DRIVE NOT READY when you try to load something without a disk inserted). The really weird stuff starts when you insert a disk. As the disk enters the drive mechanism, the spindle begins to spin, and continues for about 3 seconds regardless of the disk's continued presence. if the disk is left in until the spindle stops and then removed, it does it again.

If I try to load something from a known good disk, the drive spins and the stepper motor whirrs in a complex intermittent pattern for about 20 seconds. Most of the pattern fragments are "3 whirrs -- whirr whirr" or "5 whirrs -- whirr whirr" with the odd 4 or 6 whirrs to mix it up. All the whirrs are about the same length -- about half to 2/3 of a second. At the end of this cycle, the error light flashes and the error channel produces a READ ERROR in the 20s (I got both 20 and 27 while trying to compose this message).

Attempting the "I" command while the drive has no disk in it gives a 21 READ ERROR. Ray Carlsen's 1541 repair document recommends this step to unconfuse the drive if the head is stuck past track 18, but either it has no effect on a 1571 or it has no bearing on my problem.

I tried writing to Mr. Carlsen directly about this, as I don't know of anyone else knowledgeable, but there was no answer (I suspect my letter ended up in his spam filter). Does anyone have any ideas?

G.

I posted for the first time yesterday, and was dismayed to find myself listed as a "Windows user". I call foul! I only use Windows under duress, and never to access this forum. How do I fix it?

I see in some of the older topics here that the Kernal routines do not work around hardware bugs that can cause data loss if there is an interrupt at just the wrong moment. At least, I think that was the gist of it; the exact details are irrelevant to my purposes.

Some background:

I have rigged a direct modem-to-modem connection from my Mac (with external 28.8 modem) to my C128 (with Model 1670 dangling off the user port). I am working on a simple BASIC program, maybe with machine language subroutines if I need them, to access D64 images on the Mac via Zmodem and a terminal emulator. (The idea is that I can Zmodem across a D64 image and copy it straight onto the 1571 as it arrives, with just a bit of overhead for the file transfer voodoo. It doesn't matter how clumsy it is -- once it works, I can find, download and copy across something better.)

My question is, am I going to have to roll my own serial routines, or do the errors not really affect a transfer as slow as 1200 baud? Any advice will be appreciated.

G.