Jump to content


  • Content Count

  • Joined

  • Last visited

  • Days Won


Snickers11001001 last won the day on July 26

Snickers11001001 had the most liked content!

Community Reputation

51 Excellent

Recent Profile Visitors

The recent visitors block is disabled and is not being shown to other users.

  1. Thanks! Well, that's some extra maths I guess I need to work on, LOL. ETA: That also seems to answer another question I had about the need for 10 bits to represent the vertical position given a 480 pixel high screen. Thanks again!
  2. Dumb question as you guys are talking sprites. Is there an offscreen offset? What I mean is if I want to have a sprite sort of drive onto the screen from the left side, can I set the sprite to a particular location that's outside the display and sort of scoot it in? Sorry for the dumb question.
  3. I can't seem to find video of the whole thing. Just little clips. Youtube is prioritizing clip size for people with the attention span of a gnat. Anyone got a good link?
  4. Scott! Wowzers! That's amazing to think about! Of course, there's already a lot of this sort of thing in 'the other direction' in the retro computer community. I have to take great care not to be a jerk when I see someone post on REDDIT about how their brand new VIC20 game blows away anything that ever existed at the time the machine was 'in general use' and how the original programmers must not have been any good etc., etc. Of course their new VIC20 program was put together using a cross development environment running on a modern machine with more than half a million TIMES more transistors; repeatedly (and instantly) compiled right into VICE or whatever emulator of choice for testing. The graphics were prepared using photoshop and illustrator and other utilities (having a combined code size equal to many thousands of 1541 disks); and thanks to the internet, with the benefit of having access to code libraries and disassembled code from virtually every 6502 based game app demo etc ever made! And don't get me wrong I don't begrudge folks from using those 'best available tools' for the job. But its the smug and self righteous comparisons in which they credit themselves as better programmers than the folks from 'back in the day' that tends grind my gears. I wonder what their game would have looked like if they HAD used only the same tools as the people who were programming on the old machines in the 1980s, using simple assemblers, graph paper and colored pencils for the drawings, and (on the VIC20 at least) saving their work on cassette tapes (where just the 'save' gave you time to go out and get a cup of coffee). Geez. See what I mean? I can be a real "get off my lawn" old coot when it comes to that topic!
  5. OK, ... the following is a BASIC routine to ascertain the location where VARIABLE memory starts (i.e., the value kept in 'VARTAB') from within a BASIC program. This avoids the need to rely on the actual [but potentially-not-guaranteed-to-continue-to-live-there] 'VARTAB' address utilized in any particular pre-release ROM build. As noted, I'm doing this because I want a ML routine I'm working on (and which will be called repeatedly from within a BASIC program) to grab its parameters straight out of the first couple of integer variables and this is how I'm accomplishing that for now. Ascertain start of variables address from within BASIC: Listing A: (sanity/error checks included) 1 A=$801:FOR L=0TO1:C=C+1:A=PEEK(A)+256*PEEK(A+1):IF A<$801 OR A>$9EFF THEN4 2 L=PEEK(A)+PEEK(A+1)+PEEK(A-1)=0:IF L THEN IF PEEK(A-2)=0 OR PEEK(A-3)=0 THEN4 3 L=ABS(L):NEXT:IF PEEK(A+2) THENIF((A-$801)/C)<256 THENPRINT "VARTAB =";A+2:END 4 PRINT"ERROR.":END Listing B: (big-boy pants version w/ no error checking - make darn SURE start of BASIC is correct!) 1 A=$801:FORL=0TO1:A=PEEK(A)+256*PEEK(A+1):L=ABS(PEEK(A)+PEEK(A+1)+PEEK(A-1)=0) 2 NEXT:PRINT "VARTAB =";A+2:END What it does: 'A' is set to the known start of BASIC. The routine then walks along the BASIC program line-link pointers until it gets to the program terminator. At that point, it knows what 'VARTAB' is. When you've found the end of the BASIC program in memory, you also know where scalar variable space begins, i.e., the value known as 'VARTAB'. This approach depends on following all of the BASIC program line-links, so it is essential that it starts from the correct address for the start of BASIC (which is also the first line-link). Since any 2 bytes in a row taken together refer to a location in the 16 bit address space, the wrong starting point would have it jumping all over in memory until it happened upon a series of 3 zeros in a row. Keeping that in mind, the 'Version A' listing contains several evaluations to accomplish some validity/sanity/error checking. I cannot guaranty it to be foolproof; however, I did a lot of testing and whenever Version A was pointed to some random (incorrect) starting address, whether in the middle of a program listing (or variable space, or array land, or zero page, or even the stings heap), it would fairly reliably figure that out and raise an error via line 4. Of course, if you use this in your program, it seems reasonable to assume that YOU will know without any question whether or not you've moved the start of BASIC from the standard $0801 location, so I've also included Version B which is materially faster but makes no attempt whatsoever at error/sanity checking. In my experience, although moving the end of BASIC down to make room up above for sprite data or something was common on Commodore machines; it was really rare to see a C64 or other program moving the start of BASIC upwards. So there really shouldn't be a problem here. Ultimately, I think both versions are actually fast enough for most purposes. Version A walks the line-links of a 1000 line program in about 5 seconds. Version B walks the links of a 1000 line program in just a hair under 3 seconds. So there you go. For what it's worth, this is just my attempt at something of a stop-gap. Once the X16 is officially in 'final' release, I would hope the BASIC address used by ROM to store VARTAB will be fairly stable and perhaps the devs could even ensure it won't change with ROM revisions Cheers!
  6. Everyone of the team members (i.e., those in the position to know) I've seen posting to threads on that topic have been adamant (for months) that the feature set and architecture of VERA has been set in stone. I'd say its unlikely there will be changes such as 'additional features and changes to existing features" for the VERA from the perspective of the end user, programmer, etc., on the X16. I think the most likely thing is that the hardware differences Kevin is referring to are likely something that will make the the existing announced architecture and specifications work better; or perhaps easier to implement on the hardware side; or maybe more robust or flexible -- all things that are 'under the hood' as they say. That's my take.
  7. I'll double check. My original take on looking at the reference guide was that the cursor-locate was referring to a pixel cursor and the new API for putting a character was in reference to the graphical (GEOS style) characters that go to the bitmap instead of the regular BASIC text screen. Part of me still wants to mess with a wedge as a way to parse expressions or command parameters inline in basic instead of 'poke,poke,poke,poke,sys" combos. At the moment, I'm working with a stub routine that you call with 'SYS' and it grabs its parameters from the first three integer variables. We'll see how it goes.
  8. I've always found that, more than necessity, 'simple annoyance' is actually the mother of invention. So I say go for it! There's no question that VERA and SOUND are tough (or at least tedious) nuts to crack right now. (I kinda feel nostalgic about that, since that was how the C64 was ... you had to really grind to learn the VICII and SID registers and stuff before you could make magic!) Speaking of annoyance, I've been playing with doing a little port / adaptation of one of my favorite arcade games in X16 BASIC and PETSCII graphics just to prove the speed of the thing makes it possible. (If you do make a sound API I will happily try to adapt it for calling from BASIC which will save me a lot of brain damage when I get to the 'sound' part of my coding.) In any event, I've found the annoying and repeated need for a way to do a fast and compact "locate" for the text screen, preferably with a color specification. Sure, one can achieve the result by a combination of PRINT TAB(x) and a string array holding down arrows, i.e., Y$(y) - (costly in memory and degraded performance as x and y coordinates get further to the right or bottom of the screen); or, more cheaply in terms of memory by doing a few pokes and using 'SYS' to call the kernal 'PLOT' routine (an official supported routine with a dedicated vector even on the x16 and everything!), but... like I said it reached the point of actual annoyance. So, now I'm thinking I'll revive a dubious talent from my misspent youth and actually try to package the routine as a BASIC 'wedge' for the X16. This will require using some rom calls whose addresses might change between now and the official release, but it will at least be a fun exercise anyway in any event!
  9. or you can even grok it from the basic command line: FOR I= $FFF6 TO $FFFA : PRINT CHR$ (PEEK (I)); : NEXT
  10. Michael Steil, user name 'mist64' GITHUB. The ROCK-STAR coder who has deep deep understanding of C64 and C128 kernal code (his web page has a great commented disassembly of the C64 roms) and who did a ton of work making the X16 basic and kernal roms come to fruition. The rom has 'MIST' in there as his signature.
  11. Awesome! Kevin, I'd say not to hesitate to lean on the community too: If you have a particular list of things you need (FPGA etc) to get proto stuff done, post a list and let folks see what they've got (or can leverage connections to get). Obviously it won't be the endgame supply chain, but if you need something (e.g., to get VERA4 onboard and rocking) it could be the hive mind might be in a position to help. As for myself, er... well, I've got a big bag of blue LEDs somewhere around here. In all seriousness, thanks to you and everyone on the team for plowing through all the things with COVID, the global supply chain weirdness and the online bikeshed factory to get things so this far. Can't wait for the next steps!
  12. Your mindset seems really sensible. Even if further tweaks are necessary, a release would take the community off 'pause' (avoiding any potential fall off of enthusiasm), and also acknowledge the value/importance of the work by the team members who have put so much time into the updates from r38 to r39.
  13. Thanks! I realized I'm an idiot and what I want to do might be something that can be accomplished by the all-too-frequently neglected 'USR()' command in BASIC. We will see! Cheers, Snick
  14. @desertfish: As a follow up to the above exchange.... I investigated those pseudo registers at $02 to $021. They are indeed utilized by BASIC commands. Which means the following line in the Ref. Guide is probably a little misleading: "The following zero page locations are completely unused by KERNAL/BASIC/FPLIB and are available to the user: Addresses $0002-$007F" I believe that probably what it SHOULD say is that the addresses from $0022 to $007F are unused. Almost certainly a typo, i.e., putting $02 instead of $22 as the first number in that range. More info: You can write a quick BASIC program to just print-peek the contents of $02 to $21 to the screen, then do stuff like change the 'SCREEN' mode; or print or reset the TI$ variable; or do bitmap graphics commands like 'PSET' or 'LINE' or 'CHAR' and watch the contents of those zero page values at $02 to $21 change. This makes sense, they're the parameter, return and scratch for a bunch of those new rom APIs, and obviously many of the BASIC extensions and other rom routines will make EXTENSIVE use of them. Now, it appears to me that they're only 'used' by BASIC when some routine needs them for their intended purpose as pseudo registers; i.e., to pass or return values to/from the APIs or serve as scratch pads. That means (at least so far as I can tell) that they absolutely CAN be used to pass values to a user machine code routine , IF (and ONLY) you do the pokes to put the parameters in those zero-page slots RIGHT before your BASIC program executes the SYS command, and THEN read any results your machine code puts there immediately after control returns to BASIC from the SYS call. But those locations can't be used to hold values on a read/modify/write basis (i.e., don't use them in a complicated BASIC program to simple 'hold' sprite positions or, a buffer of notes to be played in a sound routine, or as important pointers or other values that need to be used periodically throughout the runtime, because if your program does something else that invokes one of the new APIs that rely on those addresses as registers the contents will be thrashed. In my testing, I've also displayed the contents of $22 through $7F and they are indeed left unmolested by any BASIC activities I could come up with. SO... if anyone knows who is running project management for the X16, maybe have them look at this post (or put the docs person in contact with me) so we can get that line of the Reference Guide fixed. Cheers, Snick.
  • Create New...

Important Information

Please review our Terms of Use