Jump to content

Scott Robison

  • Posts

  • Joined

  • Last visited

  • Days Won


Everything posted by Scott Robison

  1. Without taking time to look, I wonder how much of the enhanced speed of the 128 relative to the +4 is due to better coding on the 128 and how much is due to the 128 MMU being more efficient at bank switching.
  2. I just wrote the following test code to see how much difference it makes. The program: As I don't have any actual hardware, I'm using WinVice 3.5, which should be adequate and illustrative if not 100% exact. It's close enough. All time reported in jiffies as it is a measure independent of the host environment. All machines are NTSC. x128 GO64: 521 jiffies (8,883,050 cycles) x128 SLOW VIC: 706 jiffies (35.5% slower, 12,037,300 cycles) x128 FAST VDC: 334 jiffies (35.9% faster, 11,389,400 cycles [roughly the same plus benefit of VIC being inactive]) xplus4: 659 jiffies (26.5% slower, 19,330,666 cycles) Just to be complete, a special version of the program that enables 2 MHz clock in 64 mode: x128 GO64 POKE 53296: 252 jiffies (51.6% faster, 8,593,200 cycles [roughly the same as regular 64 mode plus benefit of VIC being inactive])
  3. The +4 was a faster clocked CPU, which means the fact that it is slower than a C= 64 is even more "impressive". Lots of code must run to get each byte. I have to believe there would be a way to write that routine to not take the speed hit of bank switching when accessing always RAM / never ROM space while not significantly slowing down RAM under ROM, but that's just intuition. Even tripling the amount of ram for those routines (which I don't think would be necessary) would be well worth the double digit speed improvement, but that ship sailed long ago. Edit: forgot to say, the fact that the C= 128 was slower in otherwise identical BASIC code isn't surprising, since it was clocked at the same speed as the 64 (and we can't switch to FAST without the program becoming different).
  4. I don't know how I missed this for this long. I guess BASIC 4.0 was my start, as we had PETs at school. They were purchased for a computer class that wound up not happening for four years! They just sat gathering dust in the back of the math classroom and I was interested so I was allowed to use / play with them after getting my work done. I did use the disk commands because we had a dual disk drive (and printer) to go with the three systems. I wish I knew whatever happened to them!
  5. I would think the first / main reason is the amount of bank switching required. C64 BASIC programs stood alone in their address space. The increased size and complexity of the 128 & +4 ROMs no doubt necessitated fetching bytes through a routine that would bank out the ROMs, fetch the bytes from RAM, bank in the ROMs, then continue with BASIC interpretation of the data. I've not looked at the ROMs for +4 ever. I had a 128 and I know there were routines to fetch bytes from a specific bank (variables from bank 1, BASIC text from bank 0). But even if you had a program with zero variables, so you never have to switch to bank 1, you would still have to do a lot of bank switching from ROM to bank 0 RAM to access the linked list of lines of code.
  6. Now I'm afraid to go back and see how much I contributed to this discussion ...
  7. I finally got around to installing BMCBM (okay, it's called BMC64, but I think it should be rebranded to BMCBM given that it includes five different machines in one package). It booted up to the classic C64 in PAL mode. I switched to NTSC (since I'm in NTSC land) and C128 mode and I finally have a C128 again. I've done very little with it, mind you, but at least I can see it boot and can write little programs on it, as well as switch to C64 mode to play my games that were never ported to C128. Now I just have to dig around more into the settings to figure out what I can and can't do relative to a full blown Vice installation on Windows.
  8. One thing that I think might be better for an API (esp on 6502) would be to pass a pointer to a structure instead of a bunch of individual values.
  9. There is a lot to be said for source code quality and convenience of using bit fields, but remember that the compiler will be doing packing and unpacking of the fields just like you would have to. That's not a reason to avoid using that feature, but it isn't likely to improve performance (assuming the same technique is used in manually written code as is used in compiler generated code).
  10. That's a good point. I had C= 64 stuck in my head where the CPU had to share time with the VIC, but that need not be the case for a new layout. In that case, communication between CPUs could be as simple as reserving a byte with flags. One CPU sets a particular bit to "interrupt" the other CPU, and the other clears the bit to acknowledge the interrupt. Eight bits allows four bidirectional channels or whatever combination is desired. More memory could be reserved for message passing depending on the amount of data needed. Seems too simple.
  11. The hardest part of a dual processor 6502 is going to be communication between the two if they try to share memory. I guess dual port RAM could help alleviate that, though I'm thinking a "better" way (in as much as it makes sense to create a multi 6502 based system) would be for each CPU to have its own 64K of RAM with DMA circuitry sitting between the two. Then when one CPU wanted the other to take up a task, it could use DMA to quickly copy RAM from one RAM bank to the other and signal it to run.
  12. Exactly! I once computed the number of disks that would be required to emulate a Windows 10 system on a C= 64 with 1541. Let's see, the computer I'm using right now, assuming we could even fit a CPU emulation in a C= 64 without having to swap programs in and out of the address space, would need 16 GiB for RAM and 951 GB for the SSD. So let's call that 902 GiB. I can store 166 KiB on a 1541 based on 664 blocks free (I'll just assume I read and write individual blocks rather than use files which would consume two extra bytes per block, and any overhead I can squeeze into otherwise unused directory sectors). So I'll need almost 5.7 million floppies just to emulate the RAM and SSD. Undoubtedly I'd need more to emulate other aspects of the system such as video RAM, CPU cache, etc. I wonder where I can find 5.7 M new old stock floppies? Or we could go really old school and use tapes!
  13. You are in my town! I don't mean I live there, just that my name is Scott Dale ... #haha Welcome...
  14. Now I want to write a Windows 10 emulator in Commander X16 BASIC. #haha
  15. Looks like I picked the wrong week to stop drinking. Makes sense, sorry for the noise.
  16. Wait, did you type "need" when you meant I "read" a byte? I didn't use the emulator to read the ROM, I just looked at bank 3 instead of bank 0, which would be GEOS bank, not BASIC. But as I later wrote, I finally realized my mistake. I used hexdump on the rom.bin file and my mind said offset FFF8 would be the signature location because I failed to take into account the fact that each rom bank is only 16K, not the entire 64K address space. I can be dense sometimes especially when I have other things on my mind. Also: I was looking at a home built R39 I built on April 25, just in case there has been drift since then as I've not pulled any updates since then, more or less.
  17. I'm not sure I understand how one relates to the other. My only meaning was "the signature includes $FFF8 but starts at $FFF6". That is true regardless of what bytes exist in any other ROM bank.
  18. DOH! I didn't think about the rom being 16K pages. I was looking for the bytes at the byte offset, which would have put it in bank 3. Though: It still doesn't start at $FFF8, hence part of my confusion. But the bigger issue was my duh me moment expecting to see file offsets as addresses.
  19. I looked at the rom.bin image and didn't see the signature at that offset.
  20. I'm assuming it is related to Michael Steil (aka mist) who is working on the kernal. There is a four byte signature in the source code, though I don't find it at $FFF8.
  21. I work for a government contractor. I'm a software guy, but we do plenty of specialized hardware in relatively low volume. Just chiming in with "hardware shortages in the supply chain are real" ... I think I can safely say that much without getting in trouble.
  22. True. Both were amazing, and even though Opportunity outlasted Spirit by a significant margin, it is impressive everything that was done for what were supposed to be 90 sol missions...
  23. Whenever I think of personification of machines (a chip being a small electronic machine), two things come to mind: Enterprise (particularly from ST3 when she exploded) and the Spirit Martian rover (https://www.explainxkcd.com/wiki/index.php/695:_Spirit). I rather liked the alternative versions fans created. No, I didn't cry at either of those, and you can't prove otherwise.
  • Create New...

Important Information

Please review our Terms of Use