|
Post by bjonte on Jul 7, 2020 15:51:19 GMT
I don’t see how you would avoid reading lots of sectors to find the size. Even more sectors than the actual file contains.
This is kind of bending the disk format and if that’s allowed we can just store the size somewhere instead and require all writers to conform to that new standard.
|
|
|
Post by bjonte on Jul 6, 2020 9:16:41 GMT
Ah, I read something in the Mapping The Commodore 128 now.
"The RAM configuration register bits, rather than the configuration register bits, also determine which block will be affected by other DMA (direct memory access) operations, such as data transfers by the REC (RAM expansion controller) chip in the RAM expansion modules."
So I have to configure VIC to the same bank as the REU source/target. Argh!
|
|
|
Post by bjonte on Jul 6, 2020 9:09:15 GMT
I have been debugging an issue for hours now and I start to run out of options. I have ram bank 0 enabled, shared memory 0-$4000, code at $6000 roughly and I attempt to copy from C128 to REU. Whatever I do, the ram that's stored on the REU is fetched from bank 1. I tried immediate transfer and the delayed transfer that is triggered by a write to $ff00 and even if I point at bank 0 the data is copied from bank 1.
The thing is, if I make a stand-alone program that does this simple store and fetch, it works as intended. In fact I have REU detection code that's running a bit earlier in the program that works. So it looks like I do something to lock the REU into only accessing bank 1. Speed is 1 MHz, interrupts are disabled, nmi is disabled. How is this possible?
Here's a hex dump of the relevant code.
6370: a9 00 lda #C128_CLOCK_SPEED_1_MHZ 6372: 8d 30 d0 sta C128_CLOCK_SPEED 6375: a9 b8 lda #<hex 6377: 8d 02 df sta reu::C64BASE 637a: a9 63 lda #>hex 637c: 8d 03 df sta reu::C64BASE + 1 637f: a9 00 lda #0 6381: 8d 04 df sta reu::REUBASE 6384: a9 00 lda #0 6386: 8d 05 df sta reu::REUBASE + 1 6389: a9 00 lda #0 638b: 8d 06 df sta reu::REUBASE + 2 638e: a9 00 lda #0 6390: 8d 07 df sta reu::TRANSLEN 6393: a9 01 lda #1 6395: 8d 08 df sta reu::TRANSLEN + 1 6398: a9 00 lda #0 639a: 8d 0a df sta reu::CONTROL 639d: a9 a0 lda #reu::EXECUTE | reu::LOAD | reu::TRANSFER_C64_REU 639f: 8d 01 df sta reu::COMMAND 63a2: a9 3e lda #MMUCR_RAM_BANK_0 | MMUCR_4000_RAM | MMUCR_8000_RAM | MMUCR_C000_RAM | MMUCR_D000_IO 63a4: 8d 00 ff sta MMUCR
|
|
|
Post by bjonte on Jun 27, 2020 18:38:20 GMT
A very nice trick!
|
|
|
Post by bjonte on Jun 19, 2020 4:51:36 GMT
On my C128DCR (where I won't open the computer at this time so no ASSY or CIA types) I get these results.
4 - green 5 - green 6 - green delay2-new - green delay2-old - red new-50 - green new-51 - green new-64 - green new-7 - green new-8 - green old-50 - red old-51 - red old-64 - red old-7 - red old-8 - red
|
|
|
Post by bjonte on Jun 19, 2020 4:36:43 GMT
I didn't want to open my DCR, but I did open my C128 to take a photo of the motherboard. Sadly, the assy number must be on the back side since I can't find it. CIAs are both MOS 6526 2685. There is an 'A' on the left one.
4 - green 5 - green 6 - green delay2-new - red delay2-old - green new-50 - green new-51 - green new-64 - green new-7 - green new-8 - green old-50 - red old-51 - red old-64 - red old-7 - red old-8 - red
|
|
|
Post by bjonte on Jun 17, 2020 17:48:20 GMT
Yep, but not too many. I tried to become a serious GEOS user once but gave up on it. I just felt too restricted by its drive limitations.
|
|
|
Post by bjonte on Jun 15, 2020 11:06:55 GMT
Artifacts on which screen?
|
|
|
Post by bjonte on Jun 4, 2020 10:57:23 GMT
Not a bad idea for the DCR which consumes a lot of table space.
|
|
|
Post by bjonte on May 20, 2020 15:38:53 GMT
What’s the connection between CX16 and Apple?
I agree it is unlikely at best to see major development on these new platforms. It’s such an undertaking to make serious games for these platforms. Even the mighty C64 doesn’t get more than a handful of serious games per year.
|
|