Jump to content

Snickers11001001

Members
  • Content Count

    32
  • Joined

  • Last visited

Community Reputation

29 Excellent

Recent Profile Visitors

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

  1. I think I saw someone was going to code up an extension for the pi1541 that allowed a speaker to output those sweet seek and spin sounds, sort of like the VICE emulator does.
  2. This reference will have all you need for the C64. http://www.1000bit.it/support/manuali/commodore/c64/Commodore_64_Data_Files_A_Basic_Tutorial.pdf Once you get an understanding of the basic framework -- all disk operations on C64 are one computer ( the C64) talking to another computer, (the disk drive --which has its own 6502 processor and operating system) -- you should consult Chapter 10 of the attached for REL files (which are random access). Warning: Most of the emulators in my experience don't support or are very buggy in doing "REL" files. Plus, since there's the slow I/O, the performance is not great. Unless your BASIC program is so big that there isn't room, I always suggest considering one of these alternatives to trying to do REL files: a) put the information from the REL files in DATA statements as alphanumeric hex data, e.g., "DATA F1, C0, 11, A3," Create a random access routine to get your information from DATA statements. You set a Variable to an INDEX to the position in the DATA statements you want, then you execute a RESTORE, followed by a for/next loop that does throw-away reads to that the number of reads equals your index minus 1. After exiting the loop, do your next READ. As you can see this is wasteful as hell and performance degrades in a linear way the later in the data set you need to go. One way to deal with this is to add a quick machine code 'wedge' (see Commodore Transactor journal issues, they had these) that lets you 'RESTORE' to a particular line. But if you are smart in how you structure things and the data list is short enough, the actual time from fetch to use can often beat the slow 1541 disk accesses. b) Better still, format the data you want to have random access to into a binary file and have the first two bytes of that file set to a 16 bit address (be aware of the low/hi byte ordering) that is equal to the length of the data set subtracted from the 'normal' top of basic address, or if your data is less than 4K you can stick it in the sweet 4K of ram at $c000 to $cfff on a C64 which is always a safe place. If you can't use the C000-cfff area, then your BASIC program a) uses a POKE to move down the top of basic by the size of the random access data; b) loads the binary file to the memory block freed up by doing so; and then whichever approach c) you create a subroutine such that you set your index into the data into a variable and then your subroutine returns a result variable that is equal to Peek (B+I) where B is the base/start address of the memory block and I is the index pointer to the data you want. If your data items are longer than a byte, you set up the routine so you pass it a starting index offset and have that offset in the data file contain the number of bytes to read. This takes some work to do right but its fast. Both of the above are better than messing with trying to do random access files on a C64
  3. No doubt. Because those sensors and the network to communicate with and poll their status arose out of a classic engineering question: "We have this capability, can it make our solutions work better, faster, more efficiently and how?" But that's not necessarily "IoT" - so far as I'm concerned, its networked management writ large and using the global network of the internet as a free routing and carrier infrastructure. Nowadays, "IoT" has been coopted by the business school types who sit around trying to figure out ways to sell connectivity for its own sake, without identifying a problem/solution set where it can help. And that's because the "customer" for them is not the schmuck who buys the networked device. Nope, the "customer" is big data and the advertisers (and government offices) who will pay handsomely for the resulting databases. The guy who buys the device along with that data about his habits and comings and goings and doings and whatnot are the product. The device is just a "helper object" to get that product to those real customers who want to pay for that data.
  4. Dang, hadn't thought of that one. That's dirty. Police already abusing the RING doorbells as warrantless surveillance nodes. I remember reading 1984 in high school thinking it was 'over the top.' Never in my wildest dreams would I have thought people would bring big brother into their homes and PAY for the 'privilege'
  5. As to the last point, the astonishing thing is that IoT makes it possible for unscrupulous corps to MAKE that stove break. "Sorry, preheating is no longer supported at this subscription level." I'm just kidding, sorta. But I def had had 'older' apple devices take an update that was supposedly only for bug fixes and immediately crater in terms of battery life or performance. That has to be on purpose to feed the upgrade cycle. There's an amazing youtube video that came out recently about the "lightbulb" cartel having a a meeting long ago to standardize to a much lower lifespan for light bulbs. They actually included a mechanism to FINE each other if someone made a better lightbulb. Also, part of the problem with IoT is something that crept into "big gaming" the last decade or so: As soon as something's connected to the internet, its hard for middle management to avoid falling victim to the "push it out the door, we'll patch the bugs later" mindset. (My kids didn't get to PLAY any of their Christmas games even 5 or 6 years ago because the machines would take hours and hours or so to download and install the day 1 and subsequent patches! What a contrast from unboxing Coleco, Atari and Nintendo games and playing all night when I was a kid).
  6. Alas my 6502 assembly was limited to a couple routines I coded trial and error (mostly error) in the Plus4 MONITOR to speed up some game stuff, and as that was 1986 or so I'm not really qualified to read or get what may be the issue: Anyone with the chops wanna give it a look?: https://github.com/commanderx16/x16-rom/blob/a200d6266038fc5ff506280e70383e5774bd0ac9/basic/graph.s
  7. Yeah, but look at the screenshot. It DOES clip for text that would flow off the right side of the screen. But whatever its doing on the Y<6 parameter, its not simply a wrap around or overflow because of where the character is landing. Look at the purple/green hashes in the screen shots. Just weird.
  8. I personally have fallen into the "nope, hard nope" to most conceptions of IoT, save for audio/visual mediums where streaming content practically necessitates it. This viewpoint arises out of the fact few industry leaders are approaching it from a functionality and quality of life mindset. Instead, the mindset seems to be: "How do we monetize people's refrigerator, laundry, doorbell, lightswitches, etc., usage?" Net connected televisions are a natural evolution with streaming and all the cord cutting that followed. But no one will ever convince me that my coffee maker needs to be connected to the global network. And there's no real functionality for the consumer. "Oh, I can schedule it over my phone... but who puts the grounds in and fills the water?" See photo attached! (Hell, at any rate, when I have guests, I tend to break out the 1941 vintage Farberware 12 cup percolator -- the coffee is not as good, but it looks and smells damn good making it!). As for the X16, its an 8 bit processor running at most at 8 mhz and without the architecture that can even handle the maths for modern network comms encryption. Some guy made a utility to scramble 1541 disks on a C64 using AES and due to the particulars of AES it performed fine, which is to say fast enough that the abysmal 1541 speed was the bottleneck. But AES performs especially well on 8bit processors, and some of the network security 'gotos" do not. But by and large I suspect that any connectivity framework for the X16 would have to treat the machine itself as terminal, and have all the security handled outside the machine's boundary with I/O. So you would need a card or a dongle to talk to that central server or cloud instance, not the x16 itself. That means more hardware dev, expense, etc. And for the X16 what functionality really would benefit: Mainly a file server, like the old BBS systems. Some of the amazing demos aside, no one is really going to do video on the machine and streaming audio would be better handled by other devices and is such a crowded market the X16 can't compete either in terms of capacity or playback. Also with the presentation you provided (still watching it, but its fairly interesting and a little scary), I would say that the "IoT" moniker is getting more and more tainted with all the security issues and maybe it would be best not to besmirch the X16 brand with the label!
  9. I might think so if it was just off vertically, or off by the height of the character. But it's off by a lot and with other oddness. I've added a screenshot in my opening post above to illustrate. Notice that the boundary handling on the right side of the screen does well: If you put something that's too long to print, it goes as far as it can in terms of printing whole characters and then stops. Even the screwed up behavior in the Y parameter still has the string trimmed (brown example in my screen shot) because the code is aware that with the X coordinate supplied by my commend the rest (should) be offscreen if the string printed where it was supposed to. But as you see, in the CHARs with a Y<6 ('light red', 'green,' and 'brown' examples in my added screenshot) the deviations are (a) the top is cut off by the amount it WOULD need to be cut off to print a partial character had it appeared on the top of the screen where directed; and (b) it is mistakenly put at an entirely different location on the bitmap both in x and y, but at a location that multiple tests suggest may be some constant offset away in VERA memory.
  10. Yes, CHAR does Y as baseline as a norm for the CHAR command. But the issue is that there's something wrong with out of bounds handling at the top of the screen. If the character is 7 pixels tall, then setting a CHAR to put one onto the bitmap at a Y<6 should either do nothing, place the character but cutting off the top, or raise an error. What it currently does is CHAR somewhere else on the screen completely, which is what I think is unexpected and appears to be some sort of fault
  11. Ran into this playing with BASIC this past weekend. Particulars: Running R38 on Windows 10. Starting the program with Scale -2. Using Screen$80 to pull up the bitmap, no pokes or other funny business with the registers, just using X16 basic. Plotting a "VERA charset" text character to the bitmap with CHAR generates odd behavior whenever Y<6. Example (after SCREEN$80 to to go bitmap w/text overlay): CHAR160,6,4,"#" - places purple hash character flush to the top at roughly the center of the screen. This is expected behavior. CHAR160,5,4,"#" - places purple hash character with top slightly cut off several rows lower and maybe 64 (ish) pixels to the right. Not expected behavior. Reducing the Y coordinate further still results in the same plotting offset down and to the right of expected coordinates, but with the character moving further up and more of the character's top being cut off. I see the examples on the Programmers Ref. Guide adding '6' as a starting base offset for the Y coordinate in the examples, so it seems folks are aware of this. I wasn't sure whether this is a known issue that is corrected, or if it is somehow 'expected, although inconvenient' behavior that cannot be altered. Given that it appears the specified coordinate in an x16 CHAR command refers to the lower left of the character it makes sense there would need to be an offset. (My personal preference might be to have the coordinate of the CHAR command refer to the top-left pixel of the character, but since characters are always bigger than pixels there still needs to be boundary behavior considered). Still, it seems to me that if the specified coordinate would put part of the character off the bitmap it should either ignore the characters in the CHAR command that would need to in part print offscreen (like what happens if you try to CHAR a character or string that would run off the right side). It probably should not dump a partial character or sting at an unexpected place on the screen. Edited to add screenshot: The up arrows point to the "Y" parameter, and the commands show the odd behavior when Y<6
  12. Version .03

    6 downloads

    Continuing to re-acquaint myself with BASIC. This is just a quick BASIC adaptation of a bitmap starfield, which also pops up the X16 logo that is included in the VERA typeface used by the "char" command in bitmap mode. I messed with this about 10 years ago on a real Plus/4 and it was even slower! I believe it was based off a C64 version that a friend had bundled with one of those extenders that added graphics commands as a wedge to C64 basic. There's a probably an easy way to add some depth-cue for the logos, maybe use just a single pixel for the 10% of the center of the screen; then a lowercase 'x' for the next 20% and then pop the logo to fullsize for the rest of its range of travel, but even adding color and flipping back and forth between stars and logo characters slowed things down enough that I cannot imagine further extensions it being worthwhile for a simple little BASIC demo like this. Usage: Alter the combined number of stars/logos with the 'I' value in line 1. Alter the ratio of stars/logos by changing the AND mask in line 2. Use any key to exit back to the text screen.
  13. BASIC x16 STARFIELD View File Continuing to re-acquaint myself with BASIC. This is just a quick BASIC adaptation of a bitmap starfield, which also pops up the X16 logo that is included in the VERA typeface used by the "char" command in bitmap mode. I messed with this about 10 years ago on a real Plus/4 and it was even slower! I believe it was based off a C64 version that a friend had bundled with one of those extenders that added graphics commands as a wedge to C64 basic. There's a probably an easy way to add some depth-cue for the logos, maybe use just a single pixel for the 10% of the center of the screen; then a lowercase 'x' for the next 20% and then pop the logo to fullsize for the rest of its range of travel, but even adding color and flipping back and forth between stars and logo characters slowed things down enough that I cannot imagine further extensions it being worthwhile for a simple little BASIC demo like this. Usage: Alter the combined number of stars/logos with the 'I' value in line 1. Alter the ratio of stars/logos by changing the AND mask in line 2. Use any key to exit back to the text screen. Submitter Snickers11001001 Submitted 04/20/21 Category Demos  
  14. Many years ago I had an assembler on the Plus/4 that a guy in the California Plus4 users group mailed me on disk. It was a modified version of the SPEEDSCRIPT word processor. It was two pass, I think, and I did a few things with it when I was ready to get beyond futzing around in MONITOR and keeping track of my own addresses/variables/jumppoints in on scrap paper. The source came with the disk, so maybe it would be an interesting native assembler for the Commander X16. Let me search around a bit and see if I can find it on any of the Plus4 sites. Edited: Man, the guys on Plus4 World have EVERYTHING. They really do. Here's what I was talking about: http://plus4world.powweb.com/software/ASMP4 I've attached the readme from the archive at the link, to this post. Not sure if anything there would be of help to someone working on a native X16 assembler but who knows. The program was highly tied to Speedscript and its commands/editing interface, which was just as text-based-"lookit up or memorize it" as all the other wordprocessors of the day, but maybe there's something in the code that would be interesting? Lookis like the source code is included, but I think it has to be read with SPEEDSCRIPT as I can't pull it up in a text editor. Was speedscript stored in Screen code? Maybe that's the issue. I'll have to install the VICE +4 emulator and see what I come up with. ASMP4HLP.ASC
  15. I had a Colecovision as a kid and came across a set of 3 broken ones at a fleamarket, probably 2004 or '05 or so. Never did a lot with the hardware, but I researched online and taught myself enough to figure out that the weak spot was the 4116 RAM chips used for video memory. They required +5, -5, AND 12 volts to operate. And the Colecovision main switch was only a double pull which means, yep, the -5 was always supplied to the board when the power supply was plugged in, which made sense since the datasheet said -5v had to be powered first to polarize the substrate. Colecovisions were already notorious for the power issues and a dirty power switch always caused problems. So after studying the pinouts, I made a rather drastic mod that it turns out lots of other people also independently figured out, and I would have earlier if I had looked at the arcade board enthusiasts. I bought a bunch of tubes of 4164 drams for $2 at a local electronics wholesale place. (I think I still have dozens of these somewhere on the bench). These were the same as the 4116 in terms of most of their pins, except (a) instead of 16k x 1 they were 64K x 1; but more importantly, (b)they needed only +5 volts to operate -- no need for +12 or -5 volt rails. So you could drop these in and all you needed to do was keep the +12 and -5 not connected, tie a little jumper to get +5v to the correct pin, and tie the extra address line low through a resistor. Yes, HIGHLY wasteful in terms of only using 25% of the capacity, but it was close to a drop in solution and worked perfectly. Also, the 4164s ran a LOT cooler. Like very noticeably cooler, which was also a benefit. As I recall, you couldn't get rid of the 12 volt completely because it was used in the RF box, and you couldn't get rid of the -5v because Coleco did some wierd mumbo jumbo that needed it for their controllers, and at any rate I used the +12 for my transistor based A/V mode that added Composite audio/video out without disabling the RF box. That was a nice little mod, and I still have the Colecovision that was the best of those three (also modded the controllers with microswitches for the joystick inputs for reliability too), and its still going and going.
×
×
  • Create New...

Important Information

Please review our Terms of Use