|
Post by gsteemso on Jan 25, 2021 20:49:07 GMT
I, ah, did a worse-than-usual job of framing that question, didn't I? I'm sorry. Yes, you correctly deduced what I was trying to ask -- I wanted to know how the board's electrical loading compared against the older construction methods involving, I don't know, a big array of 4116s or whatever else someone had available. I _reeeeally_ didn't intend for it to sound like a snotty request for unpaid design review services. *wince*
But yes, the usual thing for the 256K mod is to just add two more flat DRAM banks of 64KiB each. Expansions beyond that involve either trying to guess how the C128's native 1-meg MMU design was _intended_ to be fully realized, or simply ignoring it entirely -- kludging in a PET-style block-swapping scheme instead, controlled through an extra 6522-type peripheral chip with I/O port(s).
I'm fairly sure that one design I saw, years ago, actually combined both approaches -- three quarters of the MMU banks were simply 64K blocks of RAM, while each of the remainder were 64K arrays of smaller, independently-mapped blocks. (I can't recall, at this point, whether those were mapped in 4K at a time or 16K at a time. I suppose it doesn't actually matter at this point.)
|
|
|
Post by gsteemso on Jan 20, 2021 19:31:55 GMT
A very nicely assembled little unit! Looks pretty slick when mounted.
I am curious as to how adaptable the design is. One of the more interesting types of C128 modification is to personally add some or all of the missing onboard RAM banks.
(As we know, the system ROMs have complete support for RAM banks 0-3 even though they shipped with only banks 0-1 installed, and even the (8722? I think?) MMU includes everything needed to operate them... except for the two bank-select lines, which were not brought out on their own pins because it saved a lot of money to stick with a standard 40-pin DIP case.)
The simplest RAM-expansion mod I'm aware of piggybacks a second MMU and layer of DRAMs on the first, with a couple of the added MMU's address lines swapped; that way the original MMU does its job most of the time, but whenever you activate banks 2 or 3, the extra MMU sees it as bank 0 or 1 and activates one of its bank-select lines... which are connected to the extra layer of DRAM chips, which are used as banks 2-3.
If one of these boards is present instead of a huge array of DIP-chip DRAMs, would adding a second copy of the board work as desired? (With its much lower power draw, I would expect it to at least not come out _less_ stable, but these things continue to surprise us even after nearly 40 years.)
|
|
|
Post by gsteemso on Jan 20, 2021 18:56:37 GMT
I do maintain my original point that the end of the file can be determined by a continuous read of track and sector pointers, and that there is no other, or faster way for larger files. Agreed! That's pretty much exactly what I was trying to describe, though I have to admit, when I start expounding upon such things I tend to be very unfocussed, with a lot of excess detail, and frequently get side-tracked with interesting but not-totally-germane tangents. With respect to "EOF": For some reason, my brain interpreted that as "an EOF character within the data-stream being loaded", as I'm told is the convention on systems such as UNIX. The "end of data" flag in BASIC's "STatus" variable does indeed indicate EOF, just as you say. I somehow missed that that's what you meant. In short, I'm sorry for having been even less clear than usual. (I hadn't actually realized I _could_ come across that much less coherently than I usually manage. Rereading my post with a slightly clearer head was an unpleasant surprise.)
|
|
|
Post by gsteemso on Jan 20, 2021 17:35:02 GMT
There are a bunch of things that might be happening, here. First, which video-out port did you connect to? The round socket for VIC-II video is exactly the same on a 128 as it is on a C64, being old-style TV format; while the DE9 port for 80-column video is pretty close to standard CGA -- except that one of its 9 pins carries a black-and-white image of the 80-column screen formatted as - again - old-style TV.
Both video signals are active at all times, whenever the computer is powered on. You can select which one the 128 treats as "active" at bootup by the latching 40/80 key on the keyboard, and while it's running by issuing a "GRAPHIC {number, options}" command in BASIC 7.
It sounds to me like you've had both 128s hooked up only by their 80-column ports, with one of them not showing any text because it's booting up with the 40-column video "active" which you don't have anything connected to, and the other connected to the black-and-white TV-format signal instead of the RGBI signal in the 80-column-video cable.
Computers of that era and earlier were often built with similar video-out formats emitted from completely different cable sockets, and even when both socket and format were the same, quite often the pinouts weren't. (For example, nearly every Mac and every Mac monitor used to have a DA-15 video port, but the first ...maybe 8 or 9? models that had them were all wired up differently!)
In other words, even if it looks right, you can not always assume your cable is correct unless you have verified its pinouts yourself with an ohmmeter or continuity checker.
I know from my own machines that some Commodore monitors had a bunch of option-swapping switches to try and work around the problem. If yours has any, are they all set to the right positions?
|
|
|
Post by gsteemso on Nov 29, 2020 17:42:14 GMT
Nicely done, but why? What circumstance could prompt total replacement of my 128's system RAM? I'm totally lost as to the use case.
|
|
|
Post by gsteemso on Nov 29, 2020 17:26:16 GMT
...."EOF"????
Commodore DOS doesn't really _use_ any kind of explicit EOF, unless you count the "end of data" handshake on the IEEE-488 or Commodore serial busses.
The on-disk format of a SEQ or PRG file, as discussed, divides each 256-byte sector into 254 bytes of data preceded by a two-byte next-sector pointer. The first byte of the pointer records the track, and the second records the sector on that track. The track number must be in the range [1 - 255]; when this byte instead contains a zero, that means the 254-byte data field holds the last portion of the file, and is most likely not completely used. The index (i.e., byte number) of the last data byte within the _sector_ -- not within the _data block_ -- is stored in what would otherwise be the next-sector number, in the second byte of the raw sector. Because bytes 0 and 1 of the sector are not within the data block, the valid range of this datum lies within [2 - 255].
So, I'm honestly having trouble finding the trouble. If your algorithm already knows to load each sector, read the two leading bytes, and loop, then that's it. What else do you need?
Load a sector. If sector-byte #0 is nonzero, add 254 bytes to your file length, and loop. After the loop, take (the contents of sector-byte #1) minus two, and add that to your file length. Done!
|
|
|
Post by gsteemso on Aug 17, 2020 8:29:35 GMT
I've seen it reported that PAL and NTSC interlacing procedures are opposite of each other: one format does even fields first, the other does odd fields first.
Knowing Commodore, they probably ignored the whole subject -- if the two fields are "always" the same as each other, as generated by the VIC-II, who even would notice?
|
|
|
Post by gsteemso on Aug 11, 2020 5:40:42 GMT
I hit "report" with a reason of "spam" whenever I encounter one of these. There is a delay of anywhere from a few hours up to a month or two before whomever receives them notices, but it has always hitherto happened eventually.
|
|
|
Post by gsteemso on Aug 3, 2020 20:40:19 GMT
If you have your terminal emulator configured for Unicode (usually done as UTF-8), and a suitable font installed, there are in fact a bunch of things like the box-drawing characters from DOS and an assortment of quarter-cell and 1/6-cell block-pixel pseudographics in Unicode. With the terminal & font set correctly, all you're missing is a keyboard layout. (Unfortunately, those aren't simple on Linux, or most other Unix derived systems.)
I believe there's a program (CGTerm?) that does all of that internally, meant for dialling into Commodore BBSes, but I'm not at all sure how you would set up Linux to understand the PETSCII it sends.
|
|
|
Post by gsteemso on Aug 3, 2020 20:28:42 GMT
sorry, I'd misread the question & failed to catch the part where you were starting from an assembly-language subroutine. Is this in the best subforum for that?
|
|