Jump to content

kelli217

Members
  • Posts

    257
  • Joined

  • Last visited

  • Days Won

    2

Everything posted by kelli217

  1. Yeah, I have been dealing with some trigonometry in a project I'm currently in the "thinking really hard about it but not yet writing anything down" stage. And the realization came early that the X16's BASIC was slightly lacking in trig functions. All I'm worried about at this point is 'is this project even possible' so I just thought about "soh-cah-toa" and realized that it was doable to work without a full complement of inverse functions. And that's as far as it went.
  2. Arctan is in BASIC V2, as ATN. The others aren't. There's math that can be done using the arctan function and the understanding that the radius is always 1, though.
  3. I was only thinking of how you'll probably need a PS/2 mouse for your X16 when it becomes available.
  4. At this point it's probably easier to buy a PS/2 to 1351 mouse converter. https://www.ebay.com/itm/164496390269 https://www.pcbway.com/project/shareproject/PS_2_Mouse_adapter_for_Commodore_64__1351_mouse_hardware_emulation_.html https://retrocomputerstore.com/products/ps2-to-1351-mouse-adapter-for-commodore-64-c64-128-c128 https://www.tindie.com/products/baldengineer/commodore-1351-to-ps2-mouse-adapter/ Or just search for '1351 mouse converter' on your search engine of choice.
  5. Greg Nacu's C64OS has dealt with making user interface/experience elements out of characters by... redesigning the font. Sort of like the old Apple MouseText. We don't need to reinvent the wheel here, necessarily, though... @JimmyDansbo's VTUI might be useful as a starting point.
  6. You want to know how to group things logically? You should probably take a cue from Adam Savage: The answer to "where should I put this?" is always the same as the answer to "where would I go first to look for it?"
  7. I haven't read anything about it. Is it based on the onboard graphics systems they've been selling for ages, or is it a new GPU architecture?
  8. Big Commander butterfly logo splash screen. Easy enough to do, doesn't take much memory.
  9. Well, most of the Infocom games were released for CP/M, until they started including graphics, so take your pick. But the killer business apps were probably WordStar, Multiplan, and dBase II. There's also Turbo Pascal, several versions of BASIC, and a couple of C compilers.
  10. Archive.org has a lot of abandonware, available for download or for playing on their online emulators.
  11. That's because the program must now be started from the command line with the switch -rtc in order for the real time clock to function and produce the data for use in TI$. (IMHO, the RTC being active should be the default state of the emulator—and I'm guessing that it probably will be, once Michael has verified that it works properly and conforms with the behavior of the real hardware.)
  12. Sven, it's quite useful to read the Wikipedia entry on the processor. It is not an in-depth programmer's manual, but it gives a surprisingly comprehensive overview of the architecture. https://en.wikipedia.org/wiki/WDC_65C816
  13. Does it actually have SDIO support, or just SD storage?
  14. It does change things up a bit. There was at least one run where there were only four pixels left.
  15. I've been messing around with the emulator a bit, playing with programs that I used to type in for fun all the time back in the day. The first computer I ever used on a regular basis was the TRS-80 Model III down at the Radio Shack in a nearby shopping center. And it had some pseudographics commands. SET, and RESET. They're very similar to the PSET command. The program that I am thinking about at the moment was the one for filling the screen with random pixels until the whole screen was full. It took a while, but eventually, every pixel would be filled in, and at that point I'd hit BREAK and move on to the next activity. But while the TRS-80 BASIC would eventually fill the screen, X16 BASIC won't. Using exactly the same 128×48 grid that the old Z80 system used, trying to use the RND() function to fill the screen results in a few pixels always being left over. I know that the available routines have a fairly short periodicity, so I tried to enhance the randomness by recursive randomizing. But still, even using RND(RND(1)*32768)*[number of pixels] for both X and Y, this is the best it will do for a 128×48 grid: I ran that at top speed for an hour, and that's as far as it got. Those white pixels never get filled in. If I try to fill the entire SCREEN $80 grid of 320×240, it's much worse. I would use RND(0) as the inner seed, but it's my understanding that it's even more repetitive, at least, going by the C64 Wiki's article on the function. While I don't know much about the TRS-80 version of the function, and I know it's still a pseudo-random number generator, it seems to be a little better at covering a wider range of values more comprehensively. Is this just something we're stuck with, and will just have to code our own, or is there a way to shoehorn in a better PRNG algorithm into the stock interpreter? Or is there a workaround to get better results out of the existing RND() code?
  16. Yeah, the version in your post works great.
  17. Is there a way to make the player stop moving other than hitting the left or right side of the playing area? When I play on the web emulator I can't seem to stop in place, and that would be really useful.
  18. Yeah, what ZeroByte said. I distinctly recall getting a program listing in a file by doing the thing we used to do with printers, with OPEN, CMD, LIST, PRINT#, and CLOSE, only with a sequential file as the destination rather than the printer device.
  19. If it counts, the later Apple IIgs models came with 1MB installed... actually it was 1MB + 128K.
  20. And don't forget the Commodore 900. The Z-8000 based machine that ran Coherent.
  21. 1000 REM HEX$ FOR CBM BASICS THAT DO NOT HAVE IT 1010 REM ONLY SUPPORTS UP TO 16-BIT ARGUMENTS 1020 REM CALL AS GOSUB WITH ARGUMENT IN DC 1030 REM RETURN IN HX$, TEMP VARIABLE HD$ 1040 HD$="0123456789ABCDEF" : REM HEX DIGITS 1050 HX$=MID$(HD$,(DC/4096 AND 15)+1,1)+MID$(HD$,(DC/256 AND 15)+1,1) 1060 IF DC>32767 THEN DC=DC-32768 1070 HX$=HX$+MID$(HD$,(DC/16 AND 15)+1,1)+MID$(HD$,(DC AND 15)+1,1) 1080 RETURN Usage: 340 DC=38911:GOSUB1000:?HX$
  22. Just a few months ago I was looking at the RC2014 project. It's very similar.
  23. It's almost 200 times the 31.5kHz horizontal frequency of a standard VGA signal. If that VGA signal's vertical frequency is adjusted to 'drop frame' timing in order to accommodate interlaced NTSC video at 59.94Hz field rate, then the horizontal frequency would drop to 31.4685kHz, and 200 times that would be 6.2937MHz.
×
×
  • Create New...

Important Information

Please review our Terms of Use