In 80 column 128 mode, type the following line and hit RETURN
POKE DEC("D600"),28:POKE DEC("D601"),63:SYS DEC("FF62"):SCNCLR
If the screen looks normal, you have 64K of video RAM. If the screen fills
up with zeros, you have 16K.
Quote from: xlar54 on January 19, 2008, 10:05 PM
In 80 column 128 mode, type the following line and hit RETURN
POKE DEC("D600"),28:POKE DEC("D601"),63:SYS DEC("FF62"):SCNCLR
If the screen looks normal, you have 64K of video RAM. If the screen fills
up with zeros, you have 16K.
Please refer to new post regarding the correct way to control the VDC from BASIC.
Yep, read it, thanks - very insightful. Based on what you are saying in that other thread, what are the ill effects or potential ill effects of the code above? (This code was actually found in an Abacus book)
By the way, I tried this on my real 128, and it works fine. WinVICE 1.22 seems to not report 16kb. ( ie no matter how it configured, it still reports as if it were 64kb, perhaps it's affected by the bug that bigd is refering to more readily? ).
Quote from: xlar54 on January 21, 2008, 02:29 PM
Yep, read it, thanks - very insightful. Based on what you are saying in that other thread, what are the ill effects or potential ill effects of the code above? (This code was actually found in an Abacus book)
The ill-effects are that PEEKing and POKEing the VDC are unreliable and wrong. Besides, why would you even think of doing it that way when screen editor ROM primitives that do it the right way are readily available to BASIC?
As for the Abacus book (128 Internals?), it wouldn't be the first time they got it wrong. The 128 Internals book had several glaring errors that I vaguely recall. One of them wasn't a technical error so much as one of translation from the original Data-Becker tome, which was in German, to English.
Since we're in the thread, can you help with a quick ML or BASIC routine one might call to determine 16k or 64k by using the correct access method?
Quote from: BigDumbDinosaur on January 21, 2008, 02:48 PM
As for the Abacus book (128 Internals?), it wouldn't be the first time they got it wrong. The 128 Internals book had several glaring errors that I vaguely recall. One of them wasn't a technical error so much as one of translation from the original Data-Becker tome, which was in German, to English.
The original "128 intern" is a really rotten book! Full of errors!
WTE
...like all DATA BECKER books - crap.
Quote from: xlar54 on January 21, 2008, 03:16 PM
Since we're in the thread, can you help with a quick ML or BASIC routine one might call to determine 16k or 64k by using the correct access method?
Not a perfect one (it uses some peeks and pokes but you now know how to make it better ;))
Try this nice tool: system-informations-program som jag har skrivit för C128 (http://folkvagn.commodore64.org/Disketter/Egna_program_och_projekt/C128_SYSTEM_INFO.zip) from Christian Johansson.
The code for 16k/64k RAM detection is between line 200 and 650 (with a subroutine at line 750).
WTE
Quote from: xlar54 on January 21, 2008, 03:16 PM
Since we're in the thread, can you help with a quick ML or BASIC routine one might call to determine 16k or 64k by using the correct access method?
Your wish is (somewhat) my command.
Rotting somewhere in this vast depository of refuse I call my shop are some assembly language listings of code I hammered into the 128 back in the day. I'm reasonably certain that an M/L routine I wrote for positively detecting the amount of video RAM hooked up to the VDC is in that compost pile. Once I find it, I'll get it into a format that can be somehow made available to anyone who has a MOS Technology-compliant assembler.
My recollection is that late in 1987, I was on the horn with Fred Bowen on another matter and the subject of determining how much video RAM was installed came up. Fred described to over the phone how to conduct such a test—telling me which video RAM locations to twiddle, etc. I jotted some notes and was going to start programming when Fred said he could FAX me a copy of a BASIC program he had written to do the testing, but was not always working as it should. Turns out the trouble was being caused by some
PEEKing and
POKEing he was doing to the VDC, which as everyone should know, doesn't work all the time.
Since I've never really liked BASIC, I said, "Screw that!" and using Fred's program as a guide (why reinvent the wheel) cobbled together a short M/L routine to do the testing. It worked fine on both of the flat 128s I had at the time, as well as my then newly-acquired 128D.
Since I'll be out of commission starting on Friday, I may not be able to get the source code up here for a while. First I have to find it, though. Otherwise, I will rewrite it from scratch, since for reasons that totally baffle me, I think I recall exactly how to do it. If I do rewrite it, I'll need some volunteers to test the result, since I don't have any real 128 hardware anymore and, unlike the current resident of the Vatican, I don't claim to be infallible.
See new posting in VDC subsection on testing the size of video RAM.
Obviously Christian Johansson (http://landover.no-ip.com/forums/index.php/topic,2012.msg7986.html#msg7986) used a copy of the routine from Fred Bowen (http://landover.no-ip.com/forums/index.php/topic,2020.msg8003.html#msg8003).
WTE
Ill talk to Graham about possibly extracting the startup screen from Risen from Oblivion into a seperate program. From memory it detects RAM, number of 6502 cycles per VDC line, PAL/NTSC machine, attached disk drives etc.
Ill let you know how I get on.