If memory serves, the number on the directory is called a user number, 0-15. And A is whichever disk, or drive, used to boot.
@idreamtin8bits
2 күн бұрын
Oh, wow, absolutely stoked you made a video using the software I made😮 Xander Mol, creator of CPM UTools here. And those crashes you experience are actually something I need to look into, because obviously that should not happen. My present working assumption is that I never accounted for those partitions (not sure what they called either, certainly no CP/M pro myself), so I am afraid it is looking for stuff in wrong partitions and that is why it goes wrong. So probably there is need for some bug fixes there. No time on short notice I am afraid.
@idreamtin8bits
2 күн бұрын
Hmm, apparently answers with links disappear. Just wanted to say: - there is a CP/M build in the works that can boot from REU and has the ultimate softIEC integrated. For that version you can indeed use E. - you can speed up speed of screenhandling by disabling the 40 column screen. Place the command screen40 off in your boot script. - my DM Boot software enables starting CP/M with the click of one button with disks and REU mounted automatically.
@c128stuff
2 күн бұрын
@@idreamtin8bits KZitem hates links... even links to youtube videos won't work (they do in the description of a video, but not in comments)
@paulwratt
13 сағат бұрын
those numbers after the drive letter are called "user" areas. ie one disk can contain upto 15 "user" seperated areas. Off the top of ny head, "user 14" contained deleted files, and (because you could not go past user 10) from my rather vague memory, user areas from 11-15 are / were considered "special user" areas. On CP/M when you run ANY program, the TPA (Transient Program Area) gets "unloaded", and while at the command prompt, the TPA contains the actual SYStem file (on C128 ZPM disk, "zpm.sys" ?), so if your currently active "user" area, or boot drive "user 0" area does not contain said SYStem fille, then CP/M will (obviously) crash on "exit from program".- Its similar error you get on a single floppy MS-DOS system, where your current "disk" does not contain "MSDOS.SYS" but with MS-DOS having "error recovery" via a prompt ("please insert system disk in drive X:"). So, for most versions of CP/M "to be safe", aleays copy said SYStem file to ANY "user" area you are going to run programs from, then you wont end up with those "weird chrashes" (as seen in this, and previous, video)
@FastJack42
2 күн бұрын
CP/M on the C128 was dog slow to begin with. And 80 column mode is weird as well. While the VIC is memory-mapped, the VDC only exposed only 2 registers in C64/C128 memory at $D600/D601. This made accessing the 80 column screen quite cumbersome and slow. Sometimes I wonder why the Commodore engineers went with that weird design decision. They could have mapped all the VDC's registers into I/O memory at $D6xx. But I guess they just copied a 6845 and made just enough adjustments to not get sued?
@c128stuff
2 күн бұрын
CP/M on a C128 is 'dog slow' compared to a higher end machine. It is very much on-par with a typical 'entry level' 2mhz CP/M machine, provided you use it with a 'real' 1571 or 1581 drive. Now, in 1985, most remaining CP/M machines were relatively 'high-end', so yeah, 4mhz was really kindof the norm for CP/M by that time, but is that a realistic and honest thing to compare to? Not when you consider the cost of such a machine compared to that of a C128. Not when you consider the C128 is explicitly a home computer with features to enable somewhat more serious use cases, whereas the typical high-end CP/M machine is clearly a business machine, typically not even sold through the same channels as a C128. CP/M is clearly a bonus feature, for which you payed a total of about 2 euro on top of the price of the other hardware. Compare apples to apples and oranges to oranges, and you'll find you get exactly what you pay for, a home computer which can run CP/M as a nice bonus feature. Did people use it? I don't think many did in the USA, CP/M was essentially dying there. But this did get a surprising amount of use in northern Europe, by highschool and university students, and even more so in eastern Europe where CP/M remained relevant for about a decade longer. Why the VDC works the way it does is pretty well documented (watch some of the interviews with Bil Herd, he explains that in quite a few of them, repeatedly). It is an interesting chip, but the 8563 version in the C128 is clearly unfinished. The 8568 in the later C128DCR is mostly finished... but the system doesn't make any use of the few additional features it got (such as... being able to generate an IRQ when it finished a task). Still, it is also a rudimentary 2d accelerator, and can do hardware assisted decompression of rle data. If you know how to program it, it can be fast and do some pretty interesting things for a 1985 video chip in a home computer. It is functionally incomplete, one could even argue defective (the 8563 really is, the C128 kernal has a patch to work around one of its defects, which was fixed in the 8568). I had some interesting discussion with Bil about it, it would have been great if the 8568 had been available when he was doing the C128 design, it would have helped in multiple ways... first of all it doesn't try to fry itself (so it is a lot more reliable), second, it no longer has issues due to back bias resulting in part of the first column missing, third it can actually generate IRQs... but there was no time for that. The hugely important thing to realize about the C128 is why the machine exists in the first place. Commodore wasn't going to get the Amiga out in time for the next CES, and had decided they really had to show something to keep the market interested. So, over a timespan of about 6 months, Bil and his team essentially hacked together the C128, as a 100% C64 compatible upgrade. The expectation at the time was to sell about 400k machines, and have it on the market only for upto a year, as a stop-gap until the Amiga was readily available. That worked out differently. They sold around 10 times the number of machines they initially projected, and the machine remained in production for almost 5 years (my 'newest' C128DCR has factory installed parts dating to september 1989, and while very late, it would be another 2 months before production stopped). So, any of the curious decisions with regards to the C128 are easily explained by it being a stop-gap measure which was never intended to sell anywhere near as much as it did, and was thrown together in a couple months.
@FastJack42
2 күн бұрын
@@c128stuff I was aware that the C128 was a rushed product but I don't think I've ever heard the full story. I remember Bil Herd's anecdotes about cooling the VDC with an ice cube at the CES(?) but that's all. I never realized that the VDC could do 2D acceleration. I vaguely remember that it could do block copy inside its own memory. Do you have a reference where I can look up the differences between the 8563 and 8568? A quick web search didn't turn up much except notes about IRQ pin.
@c128stuff
2 күн бұрын
@@FastJack42 The 'ice cube' thing was what the developer of CP/M for the C128 had to do, as he used a very early revision, which functionally seemed to work, but overheated quickly. TLDR, the VDC was in development for an entirely different machine, which got canceled. Bil was looking for a 6845 or alike, and got told CSG had one, the 8563 VDC. After talking to the developer of it, Bil thought it was essentially a 6845 with extra features... he should have asked a bit more, as he found out later. It has a number of issues: - designed for an entirely different architecture which makes it a bad fit for a 6502 based machine - uses its own internal clock, so you get to deal with synchronisation when the main cpu wants to read/write things (or with more expensive solutions like dual ported memory) - it was unfinished - it lacked the ability to generate an IRQ. But, those are things Bil found out on the way, and too late to change things. By the time we get to the first production version, the image was shifted 7 pixels from where it should be, which wasn't solved until the 8568 a year or so later. This was addressed by a workaround in the C128 kernal with help of the horizontal scroll register. This is also why the 128DCR needs a newer kernal version which detects the VDC version, and doesn't do this 7 pixel shift when it sees a 8568. I am not aware of a good description of the differences between the 8563 and 8568, what I know was gleamed from books like Mapping the Commodore 128, the now defunct h2obsession website, and things I found out on the way. The short list from what I remember is: - 8568 adds support for 'inverse polarity sync', which can be used to display EGA resolutions on an EGA monitor (but still limited to 16 colors) and 2 registers related to that - 8568 fixes the 7 pixel shift problem - 8568 adds the ability to generate IRQs - 8568 runs cooler and is much more reliable As to 2d acceleration, the most rudimentary 2d acceleration is hardware block copy and block fill, which VDC both has. They can run in parallel to the CPU, as long as you can make a reasonable estimate of how long they'll take, and run some other code on the cpu for that time, before polling the VDC to see if it is actually done. This is why it is so infuriating the IRQ pin of the 8568 is left unused... What it really really lacks is the ability to do block copies between video ram and system ram (both directions) using DMA... but here you really run into it not being designed for use with a 6502, and supporting 6502 style, or more specifically 6510/8502 style DMA with VDC would seem quite a big challenge (note VDC is completely disconnected from DMA on the 8510 and vic2 side, which means you can't write d600/d601 from the cartridge port, which in turn is why the Ultimate II+ doesn't have and won't get a menu on VDC) What would have been really cool is if its block copy and fill supported stencils and could do some basic operations like anding, oring and xoring with the target data... Another easy improvement would have been to be able to skip x bytes after each y bytes copied... it is easy to work around, but it would have made the block copy more convenient and a bit faster.
@c128stuff
2 күн бұрын
Very nice, cool to see a video which shows Xander's u2+ tools for cp/m. I'm sure he'll be trying to contact you about some of the issues you encountered.
Пікірлер: 10