Jump to content

Ed Minchau

Members
  • Posts

    239
  • Joined

  • Last visited

  • Days Won

    7

Everything posted by Ed Minchau

  1. This is getting off topic, better suited for another place on the forum, but yeah, fuzziness.
  2. You want to make the last valid non-whitespace character position within the string the length of the string. Set a variable (let's call it Q) to the LEN of the string. Then use a loop from LEN to 1 and MID$ to look at each character in the string. If it is a space or outside the range of your allowable characters (outside the range $21..$5F, for instance) then set your Q to your loop index minus 1. When you do encounter a character within the allowable range, you can extend the allowable range to $20..$5F and thus allow spaces within the text. Once the loop is done, string = LEFT(string,Q)
  3. Yeah, SUB in the SweetCX16.s file is very different from the other three sources listed. It's using X and Y differently too. There are significant differences throughout the code, presumably to take advantage of the 65c02 commands like BRA.
  4. Well now I don't know. I was looking at the Sweet16.s linked on Tuesday. Guess I'm going to have to look through everything now too.
  5. No, there's a transcription error there. SUB: LDX $0 SUB is used if you want to subtract the register pointed to by Y from R0. CPR can be used to subtract a register pointed to by Y from a register pointed to by X. One would be using R0 as the minuend often enough that it's worthwhile to keep those two bytes there.
  6. He also spent five figures on the new studio in the back yard. Yeah, give him a break.
  7. Simpler than that. LDA $02 CLC ADC $04 STA $02 LDA $03 ADC$05 STA $03 The carry bit from the low bytes is set if $02+$04>FF.
  8. Yeah, more like 2kb, but unlike sweet16 you can have up to 128 VM commands.
  9. I tried this: PRINT TI$ works normally. Then: 10 PRINT"HELLO WORLD" 20 GOTO 10 then I reset with a CTRL-R and typed OLD, then PRINT TI$ And I also got Invalid register 9fb7. So, the problem is likely not with FRE (or with TI$ or PRINT) but with OLD.
  10. One of the best virtual machine dispatch systems I've seen is the one in Acheron by WhiteFlame. Acheron is another 16 bit virtual machine like Sweet16, it takes only 11 cycles for dispatch. https://www.white-flame.com/acheron/
  11. R39 might not end up being an official release. They might go to R40 instead, with fixes for bugs that have cropped up in the unofficial R39. It all depends on when they can get time and source parts.
  12. Still not satisfied with the stars, I've kept tinkering and realized I hadn't updated my sprite and palette files. I kept at it and now Polaris is easily identifiable when viewing from 73 degrees south in Zoom Out view, and the Big Dipper, Orion, and Sirius are easily identifiable. There's still a small bug with stars bouncing around, but I'll get that sucker too. I changed the way I do the closeup 3d window, and now instead of using 16 layer 1 tiles it's using a single 32x32 sprite. This actually saved me about 5 kilobytes of VRAM, in addition to freeing up 16 layer 1 tiles. It also means that my zoom-in overhead view can use 4bpp tiles for layer 1 without compromising the closeup 3d view window. Looking at the remaining available memory, I should have plenty of space for everything remaining in the game: the Info button, the Stock Market button, the local area information window at the bottom, the population mood/health/numbers code, all of the Resource information, lots more sprites for things like ships in orbit or perhaps Zoom-In details, music, sound effects, and perhaps 5000 words of text for the messages and newsfeed, and various storyline events. So next is tackling that last starfield bug, then getting rid of Lorem Ipsum and putting in the actual newsfeed, then the Zoom In view. The more I work on this, the more I think this machine can do. I think a DOOM port is possible. Maybe even Halo, with a 160x120 screen and 10fps frame rate. Orion and Sirius: Big Dipper and Polaris:
  13. The idea of an edge connector is that you can have as many pins as you want. If you need 72 conductors for data/address/control, that's only 36 on each side of the edge connector, 3.6 inches long.
  14. I just watched a talk that Bil Herd gave about his time at Commodore. What was the thing he fought for on the C128? A reset circuit. And he's part of this group. If that attiny reset circuit is giving the devs headaches, maybe bring in the reset circuit ringer?
  15. Like on the X16, VERA would have been a daughter board, in much the same way Soundblaster was. Those edge connectors can have lots of pins.
  16. You're just looking to increment a 16 bit index spread across two bytes. The INC and INX and INY operations set the Z flag if the result is zero and sets the N flag if the most significant bit of the result is 1. So, if your 16 bit value is stored in say zero page addresses 7E (low byte) and 7F (high byte) then INC 7E BNE# 02 INC 7F And @ZeroByte is correct, the easiest way to save something from VRAM to file is to copy it to low RAM and save it from there. Or if it is a big file, copy it to consecutive banks of banked RAM and save it from there.
  17. Look at it this way: in the 1980s, Commodore had their own chip fabrication plant. That's how they produced things like the VIC chip and VIA chips for audio and video for the VIC-20. The VERA daughterboard is definitely something Commodore could have done in the 80s, though it would be a much bigger board. And of course we're already using 512kb RAM ICs, which for Commodore would have been an enormous PCB flooded with 2kb RAM chips. Point is, Commodore could have produced VERA, and all the rest of the Commander X16. Their only real obstacle would be the RAM, and SD storage was just a dream back then. An FPGA like VERA would have been a factory-programmed gate array rather than field programmable, or several such ICs. The ATtiny used for Reset and power on wouldn't have been present on Commodores because of the external power box feeding a single voltage to the computer, but if they had needed something like that it would have probably been done with a special-purpose chip that they fabricated themselves as well. It isn't doing a whole bunch of 16 bit or higher math, and might have been implemented with a bunch of TTL logic gates instead. If they were putting 2Mb of banked RAM in a machine, the case would already be big and would contain lots of PCBs, so what's one more?
  18. This is the same algorithm that Bruce and I both posted above. Must be close to optimal.
  19. Yep, we came up with nearly identical solutions, really just the entry and exit to the routine is the only difference. Either great minds think alike, or fools seldom differ.
  20. That's what my little algorithm above does. The result isn't 16.8, but can be shifted there.
  21. You mean 1/64 rather than 1/16, but yeah, this is basically what I was saying (my idea works out to x/64+ x/1024 ~ x/60). Your idea works out to a total of 12 lines of code, just 6 copies of LSR highbyte ROR lobyte So that's 24 bytes, but it could be even more efficient: LDA lobyte LSR highbyte ROR A LSR highbyte ROR A LSR highbyte ROR A LSR highbyte ROR A LSR highbyte ROR A LSR highbyte ROR A STA lobyte that's 22 bytes. Then, to add 1/1024 of the original to the total and get a little closer to 1/60, LDX highbyte STX highbyte2 LSR highbyte2 ROR A LSR highbyte2 ROR A LSR highbyte2 ROR A LSR highbyte2 ROR A CLC ADC lobyte STA lobyte LDA highbyte2 ADC highbyte STA highbyte This gets within 0.4% of 1/60 and totals 49 bytes.
  22. Ok I think I see. It occurs to me that if you don't care if it's exactly exact, division by 60 is very close to multiplication by 17 followed by division by 1024; the result is about 0.4% low.
×
×
  • Create New...

Important Information

Please review our Terms of Use