I recall he had retired due to problems with his hands, but upon following the link, I read that he had been caring his wife who passed last year.  I didn't know any of that.  I am sorry to read of his loss.

Quote from: ChazH on April 25, 2025, 09:25 PMthe PDF links above returns "not found"

Those posts were made 15 years ago and, unfortunately, links do go stale.  Fire up your favorite search engine and search for "mapping the commodore 128"—include the quotes with the search phrase to reduce false positives.

Quote from: RobertB on November 16, 2024, 10:29 AMOn this page, there is a method to hack a faster Z80 in order to run CP/M faster.  See

https://github.com/ytmytm/c128-z80-8mhz

Truly,
Robert Bernardo
Fresno Commodore User Group - http://www.dickestel.com/fcug.htm
Southern California Commodore & Amiga Network - http://www.portcommodore.com/sccan

Yes, the Z80 itself runs faster, but I/O is still limited to 1 MHz operation, since it is the 8502 that is doing the work.  Also, the disk-intensive nature of CP/M means performance is hobbled by the relative-slow 1571 or not-quite-as-slow as the 1581.

The CP/M implementation on the C-128 leaves much to be desired in terms of performance.  Early on when I acquired a Lt. Kernal disk subsystem, I gave CP/M a go with it.  It definitely was faster than with use of a floppy disk, but not at the level I had seen on the native Z80 machines that were available late in CP/M's useful life.  I deleted the CP/M LU on the Lt. Kernal and that was the end of CP/M for me.

Quote from: Blacklord on January 06, 2025, 07:09 AM40 years ago today the Commodore 128 was released at the 1985 CES show in Las Vegas, Nevada.

Seems like just the other day when I bought my first C-128.

Will there be anything left of LA in which to hold a convention after Mayor Bass' fire has finished its work?

Quote from: Blacklord on November 26, 2024, 05:20 AM

Quote from: BigDumbDinosaur on November 26, 2024, 01:16 AMWhich OS version are you running?

Windows Server 2022

Really?  I would have thought you'd be running some flavor of *NIX.

Can the files in RAR format be converted to ZIP?  I don't have anything that can open an RAR file.

Which OS version are you running?

It's a shame these shows all seem to be concentrated on the left coast—nothing here in the midwest of which I am aware.  It's literally been decades since I last attended a Commodore-oriented show.

Quote from: RobertB on October 21, 2024, 03:55 PMSweet!  Which reminds me that I should have Ray Carlsen install a modern power supply in my C128DCR.

I thought Ray had retired from working on C= hardware.

It's not a dual-drive assembly in the same vein as, say, an 8250.  In a real dual drive, both mechanisms have the same device number (8, 9, etc.) and a specific mechanism is selected in the command string by specifying 0: or 1:, e.g., RUN "1:MY_PROG",8.

In this dual 1581 unit, the two mechanisms have different device numbers, so the CBM DOS commands that could copy from one disk to another in a real dual-drive unit won't work.  Any copy program would be working through the serial bus to read from the source disk and write to the destination disk.  It could be made to run pretty fast by using the burst mode routines published by Commodore with the Dev-Pak assembler, along with an algorithm that understands the physical disk layout well enough to minimize the effects of rotational latency and track-to-track seeks.

With all that said, the copying speed will be limited to whatever the serial bus can deliver, which won't be nearly as fast as what even the old MSD dual drive could achieve when internally copying from disk to disk.

Quote from: RobertB on October 14, 2024, 05:48 AMThat was Jeff Jarian.  He also produced a Lt. Kernal clone.

Truly,
Robert Bernardo
Fresno Commodore User Group - http://www.dickestel.com/fcug.htm
Southern California Commodore & Amiga Network - http://www.portcommodore.com/sccan

Ah, yes, now I recall him.

Thanks for the replies.  When I finally get out the 128D, I will track down these adapters.

Quote from: Blacklord on October 01, 2024, 09:02 AMCoupled with the CPM Fast binaries (in 80 col mode) this would make the 128D a rather useful CP/M machine.

Testing 1 2 3

Now is the time for all men to come to the aid of the party.

One of my long-running projects...

Quote from: Blacklord on March 11, 2011, 08:19 PM
Another milestone reached - 18,000 post. The 18,000th was posted by Tokra.

I'm speechless, which is why I didn't make the 18,000th post.   

Quote from: tokra on March 11, 2011, 07:12 AM

Quote from: BigDumbDinosaur on March 10, 2011, 12:30 PM
Wrong.  As soon as the loop that tests bit 7 at $D600 exits and the read/write op is done a new register can be written to $D600.

Hmm, I thought so as well, but stumped over the kernal routine, copied in here again for reference:

Code Select Expand


.C:c53c   A9 01      LDA #$01
.C:c53e   A2 1E      LDX #$1E
.C:c540   20 CC CD   JSR $CDCC
.C:c543   2C 00 D6   BIT $D600
.C:c546   10 FB      BPL $C543
.C:c548   A2 12      LDX #$12
.C:c54a   20 DA CD   JSR $CDDA
.C:c54d   CD 3D 0A   CMP $0A3D
.C:c550   90 EA      BCC $C53C
.C:c552   A2 13      LDX #$13
.C:c554   20 DA CD   JSR $CDDA
.C:c557   CD 3C 0A   CMP $0A3C
.C:c55a   90 E0      BCC $C53C
.C:c55c   60         RTS

This does a check if the VDC is read before the next jump to $cdda. According to my "128 intern"-book this fixes a bug in the VDC block copy (only early revisions maybe?) that sometimes copies a byte to many. That's why the kernal copies one byte less than it should and then does the cmp $0a3d and cmp  $0a3c and copies one more byte if the VDC hasn't already - thus circumventing this bug in every case. Maybe the extra-check for the status flag is in there to make sure the VDC has finished it's block-copy before asking it if it has copied one byte too many. I can't remember having to check the status flag before setting the register in $d600 in my old programs - so I agree with your post. But maybe the error Miro is seeing really DOES have something to do with the block-copy bug in the VDC. But he hasn't addressed that part of my post at all (yet?).

The first batch of VDCs was infested with bugs, the block-copy one being most notorious (there was one other that escapes me, but had to do with driving a PAL displayâ€"it's been too long for me to remember now).  I don't know about in Europe, but by the time the flat 128 was released in North America this nuisance had been addressed.  Indeed, an examination of the 1986 ROMs seems to indicate that the workaround was no longer considered necessary.

The 128-D was fitted with the 8568 instead of the 8563 that was in the flat 128.  The 8568, while software compatible with the 8563, is a different piece and is not electrically interchangeable.

BTW, the "C-128 Internals" book has a number of errors in it, some due to the Data Becker folks having reversed a very early production 128.  Other errors crept in due to translation of the original German text into English.

Quote from: tokra on March 09, 2011, 08:37 AM
Ok, I may have an idea what you are doing wrong. It looks like you check the status register before writing to $d601 but not before writing to $d600.

Wrong.  As soon as the loop that tests bit 7 at $D600 exits and the read/write op is done a new register can be written to $D600.