Jump to content

Leaderboard

Popular Content

Showing content with the highest reputation since 11/29/21 in Posts

  1. One of the annoying things about using SD card mode is that LOAD fails when loading into banked RAM. As many know, when using the emulator without an SD image, it performs a hyperload directly into memory w/o emulating the actual file transfer. It does this by skipping the kernal routine entirely. When using SD card images, the Kernal runs as normal. Using hyperload, you can issue a command to BASIC like this: LOAD "MYFILE",8,3,$A000 This loads MYFILE into bank 3 of Hi Ram, and it is automatically continued into banks 4,5,6... as necessary. This operation fails when using Kernal (SD card attached). The same works/fails conditions apply when calling SETNAM,SETLFS,LOAD from within programs. I got really really tired of this, so I decided to fix it in the Kernal. As I'm not a code god, I'd like to see if anyone experiences any instabilities or crashes with it before I do a pull request to include the fix on the main repo. The ROM image is attached below. Use it with emulator R39 or Box16. It will not work in R38. I tested the performance with my additional code and the impact is negligible. I haven't checked what the return values look like after a LOAD into Hi RAM. The Kernal's output message gives the memory address where the load finished, and the final bank remains active, so I presume the return values in X/Y are similar. There's not much space available in the ROM so I'm trying to keep from adding too much to it. Let me know if you experience any crashes with it that don't happen using the current repo version of R39. Thanks. EDIT: Dec 05, 21:17 UTC (3:17pm Central time): Updated the attached ROM to fix a bug reported by @desertfish EDIT2: UPDATE - I've re-done the patch with a much smaller code size, saving over 60 bytes vs. my previous patch. The new one is MUCH easier code to read and follow, and it's only slightly slower. For a 96KB file I'm testing with, the previous patch took 60 jiffies (frames) to load, while the new routine took 63 jiffies. This speed penalty only happens on loads into banked memory, so I call that a win. I have updated the file here again. If you downloaded the previous ones, then I recommend that you re-download this one, as it's the one I'm using for the pull request into the Kernal repo. rom-r39-fixedload.bin
    6 points
  2. Version 7.4.1 has been released https://github.com/irmen/prog8/releases/tag/v7.4.1 Documentation as always here https://prog8.readthedocs.io Even more improvements in generated code efficiency, resulting in smaller code that runs faster. improved code generation. optimizer is now smarter about accesses to memory mapped IO that shouldn't be optimized away performance improvements in the compiler itself, updated to Kotlin 1.6 fixed some illegal instructions in the conv module on c64 target other bugfixes documentation improvements
    3 points
  3. I think David crowdfunded another project (one of the PlanetX ?) and didn't rate the experience highly
    3 points
  4. I can go out and buy one easily from Amazon, and I almost did just that last week. Not that big of a deal to get one. However, I got to thinking about Christmas 1985 when I got a C128, 1571 drive, 1902 monitor, and some dot matrix printer... and how I wanted to relive that long ago Christmas this year by unwrapping The C64 Maxi with much elation. In order to get that Commodore in 1985 I had to plot, plan, connive, scheme (basically lie to my parents about how it would help with school work)... all the usual stuff that some of us did to convince our parents it would be a good investment. Well, last week I began to annoy the living crap out of my wife about how much The C64 Maxi would be a good thing to add to our media room... Hoping to unwrap one December 25th 2021 and relive Christmas 1985... we'll see. So far it's been fun going through all the motions to drop hints.
    3 points
  5. Unfortunately the kernal doesn't know how much it's loading until it has loaded. As least in as much as the kernal works with serial IEC devices.
    2 points
  6. Re-reading your post, I noticed this bit. Actually, the destination pointer during the block copy routine is NOT page-aligned at all. And by extension, neither is the shell loop in the LOAD routine itself. LOAD could probably force the issue by requesting a block read of N bytes to become page aligned, but that would be a lot of logic to run for each iteration of the loop, and it would be fighting against the fat32 driver's attempts to keep itself page-aligned, and a full 256-byte block transfer would almost never happen. Since LOAD is high level and DOS is low level, it's probably best for DOS to get to control the flow. In debugging, I found that the very first block copy of a LOAD usually transfers $FE bytes and not $100 bytes. (PRG header removed from first transfer). Thus, when i was loading multi-bank data starting at A000, I found that the first write was FE bytes, then $100 for a few more writes. So the first bank boundary crossing was actually a 256-byte write starting at BFFE. Interestingly, this means that it's probably quite common for most of the bytes copied to incur the +1 clock cycle "penalty" for page crossing in (ZP),Y addressing mode. I'm not sure whether the source buffer is page-aligned, but I'm fairly certain that it must be. For anyone interested, the reason the 2 skipped PRG header bytes causes this is that the DOS keeps a kind of cache in bank0. It loads from SD one cluster at a time - I didn't go further down the rabbit hole to see how that operation happens and whether it scraps the buffer if you switch between two open files or anything like that. I just know that LOAD calls it, it returns all or part of the current page of buffer. When LOAD sees that it has not received all of the data, it calls "macptr" again which gets directed into fat32_read, which empties the next page of buffer. If at any point in this loop, the buffer is empty, it refills it with one cluster of data (512 bytes) until that's drained, etc. P.s. - if you told me 2 years ago that I'd end up this deep in a file I/O routine, I'd've probably laughed at you
    2 points
  7. The page thing is more optimized than that for block reads. It only checks twice per block (once in LOAD after the block transfer and once in DOS prior to doing the copy. The DOS routine now sets a ZP variable = Y index where bank swap happens. It then does a loop only having to add cpy ZP per byte. if the data ptr is < 9f00 or > BFFF then it uses the original loop that doesn’t waste time checking for page boundaries LOAD calls block read repeatedly and updates its own pointer after each call, so that pointer must get wrapped down but this check only happens roughly 4 times per KB. it would be easy enough to early exit if initial call was >= C000 and return out of memory.error, and maybe the same for page 9F. Personally I prefer the don’t do this or it crashes method.
    2 points
  8. some sort of "workaround" to load headerless files can be this: OPEN file CHRIN 2 bytes to the first 2 load locations in memory CLOSE file LOAD file in memory location+2 I built this into prog8 as load_raw() and it works like a charm, just requires a fair bit of extra code
    2 points
  9. My other favorite community, ZeroPage Homebrew, is doing a live stream at 9PM EST tomorrow (Fri 12/3) featuring the world premiere of PETSCII Robots for the 7800, including an interview with Matt Smith, (one of?) the developers of port. I'm excited to see my 2 favorite communities do a crossover episode! If you're unfamiliar with ZPH, I highly suggest checking it out. They make great shows, and the developers of the games they feature are usually in chat during the stream.
    2 points
  10. PRE-ALPHA VERSION The "pre-alpha" version is playable. I'll talk about (a) what it does now, and (b) what I WANT it to do. I'll attach the "user manual". WHAT IT DOES NOW You start in the "pilot" view, which does very little. Access the menu by hitting <return>, and you can see other things you can do. "ASTROG" is quite functional, and with it you can target an adjacent system. "MARKET" is functional but, in my opinion, needs work. "PORT" lets you refuel. "HIRING" doesn't work, currently. "SHIPYD" displays ships available for sale at this port, but it doesn't let you buy anything currently. "JUMP" takes you to your target destination, if you have enough fuel. When you Jump, you automatically take on passengers and freight. WHAT I WANT IT TO DO There are several additions and improvements I want to do. The most important to me are: SHIP DAMAGE. This means ship components can be damaged, and can be repaired at the PORT. COMBAT. Once ship damage is handled, then I can write combat. Amber and Red zone worlds are dangerous and should be avoided. The risk here is of being attacked by a pirate. I need to write a combat routine that takes your ship and crew into account. SHIP PURCHASE. The program already displays ships available at that port. The player should be able to trade in his ship for a new one, assuming he has the funds. OTHER THINGS I WANT IT TO DO A primitive "jumpstart" feature. Ship upgrades. Random ship encounters. Gas giant refueling. System survey. Hiring crew. Traveller Trader pre-alpha User Manual.pdf
    2 points
  11. You could find this topic debated hotly in that closed thread. Here were the reasons to not do crowdfunding as I recall: 1. The primary issue right now appears to be logistics, not money. Taking people's money wouldn't speed that up. Nor will increasing the the visibility of it through advertising. 2. Crowdfunding creates an obligation (at the very least, in David's view) to reach specific targets, and right now there is too much uncertainty to make any promises about the final product. The case they designed not free to the public. You are free to design your own, of course, and 3D print that for personal use.
    2 points
  12. I've actually downloaded the x16 emulator to try to learn BASIC.
    2 points
  13. The FM synthesis on the YM2151 works pretty much the same way it works in the Yamaha DX7. The biggest difference is that the DX7 has 6 operators whereas the YM2151 has only 4. But 4 operators is still plenty of material to work with. Both modulators and carriers are "operators", and both can either modulate or output sound. In "connection" 7, all operators output sound directly, in "connection" 0, only the operator 4 outputs sound, whereas the other three are modulators. I disagree with how the YM2151's manual calls the operators modulator or carrier regardless of what they are actually doing (which depends on the "connection", or "algorithm" in terms of DX7 language). I learned FM synthesis by simply seeing examples of what can be done with FM synths and how it is done, and then trying them out by myself. And a lot of messing around and trying stuff out (making educated guesses). You could start with these two tutorials, and then search other DX7 tutorials. The YM2151 does not have all the features of a DX7, but most things can be applied to the YM2151 as well. I should mention one pitfall that has confused me when I started working with the YM2151: the total level (TL) in the YM2151 is attenuation! TL=0 means max level. TL=127 means no output. The same goes for the decay level IIRC (D1L). If you want to hear something, the attack rate (AR) should be non-zero. Maybe set it to 10 or so. Higher values make it faster, low values slower. I am sure things will change slightly. The envelopes are indeed slightly slower with 3.5 MHz clock. But I am not worrying about that right now. Any patches can be adapted as soon as the official emulator moves on.
    2 points
  14. Just a note to let you all know that i'm still working on this. It is a lot of fun actually to play with the bits and the banking. I'll need to contact Jesper to optimize is cx16 compiler, but i plan to make a similar implementation for the CC65. I'll support both compilers.
    2 points
  15. Since it's been a while, and I have been spending time playing with Arduino, I found these amusing. Also, whenever you try and learn anything new... haha
    1 point
  16. @desertfish found another bug where a full-page copy would misdirect byte 0 when destination address is not page aligned and bank wrap occurs. His test bed caught this on loads to $A002, but it would have happened on any non-page-aligned block copy of 256 bytes. Fortunately I was able to save some other bytes and this patch only added a few more net bytes in size. I’ve patched this and will update the attached image shortly. @Edmond D I do want to make code that behaves as advertised. A LOAD that allows you to bulldoze the stack is one thing, but a low-level routine that just glitches in certain cases is much less acceptable. In the former case, you can at least look at the file size beforehand and throw an error before calling LOAD. But the latter is something you'd have no control over from the outside. And as @Scott Robison points out, there's no way to pre-check down to the last byte whether a read into $9E01 or not, but there is a possible way to do it. The macptr routine accepts .A=num_bytes. If .A=0 then the device decides how many. fat32_read limits to 256 bytes. I would have to go re-read the code with a non-zero amount in mind to see what would happen if an arbitrary amount reached fat32_read, but in theory, LOAD could see that it's in page 9E and then request only enough bytes to fill the page. If the return value is "still loading" then throw error. I agree that this might make more sense with a "safe load" frontend than to encumber the primary load function with this extra overhead. The changes to fat32.s were necessary for bank ram loading, even if I'd implemented a different HLOAD command analogous to VLOAD, but for HI-RAM loading.... the block copy was borked and needs to work that way regardless of the front-end packaging.
    1 point
  17. Hi! I tried your new version. After some fiddling, not properly reading the instructions, and so on, I got it to work. I wrote a simliar test hello world program to yours, and it worked great. I could also restart the assembler without reloading it from disk after compiling, loading and testing the assembly program. Very nice job so far!
    1 point
  18. My name is Pedro Crespo and I am from Portugal... I like computers/video games. Also, I am interested in content creation.
    1 point
  19. From the (limited) time I spent with this patched kernal it seems to work fine for me! So yeah go ahead with the pull-request on github. This is quite an important one, as it will probably fix a whole lot of data-load issues when running from sd-card (also I want to integrate it with my custom v39 rom build, because a few other patches are in there as well) edit: found an issue when loading to banked addresses when LSB=$02 , thinks work ok if LSB=$00
    1 point
  20. I think honk the optimal way to stop load at 9EFF would be to add one more check to the block copy routine: It does a series of checks to limit transfer size to the smallest of: full page, bytes in buffer, file bytes remaining, bytes requested by caller. Add one more check: if page is 9E then limit to $100-ptr_low. This would make LOAD start the next loop at 9F00 where it can error out. I still hold the position that this extra range checking functionality adds too much size and performance impact to DOS and the Kernal.
    1 point
  21. There's a limit to how sophisticated these things can be, given speed and size constraints of retro or retro-like systems.
    1 point
  22. Some questions from the Discord channel: The X16-docs repo is not up-to-date regarding the behavior of load. It doesn't document the VLOAD command, and explains loading into VRAM using old LOAD syntax (and old VERA banking schemes which no longer exist). Do not be misled by this errata. The intended behavior of LOAD (according to emulator behavior, and comments in the BASIC ROM source) is that it should have 2 forms: LOAD "FILENAME"[,device[,redirect]] redirect is the familiar ,1 which means LOAD will use the 2-byte file header as the load address, not start-of-BASIC LOAD "FILENAME"[,device[,bank,address]] This is the way to specify a target memory location for LOAD - the 2-byte header is simply skipped and the remainder of the file is loaded to the specified address It is this second form which I've fixed. It previously worked for destinations in main memory, but would result in bank0 being overwritten insted of the intended bank. Bank overflow was also not supported - the LOAD would just continue up into the ROM region.
    1 point
  23. I also think this is very true. I'm just a bit surprised that there happened to be no enterpreneur in old days to show the world what C128 is capable of. And I'm really happy to see that you showed it after so many years of C128 release!
    1 point
  24. I believe that the PRIMARY issue is that the design is not quite finished. I might speculate ... but it would JUST be speculation, since I am another outsider to the process ... fine-tuning the 65C02 PS/2 code timing or having the 8bit ATTiny micro-controller handle the PS/2 ports might well handle the last serious outstanding problem, then when mist has free time, the Kernel can be fixed up for a beta release, with things like the bit bang serial port and a range of the "not yet implemented" features of existing routines.
    1 point
  25. Sort of, yes. Rebranded so-to-speak, for the Canadian designed and manufactured platform stylized to match the integrated version discussed here. When I originally bought the WASD, I immediately pulled the Cmdr. keys and replace them with CBM keys, vowing to put them back on once I received the platform. A few clicks later, I'm still wedded to my vintage Commodore collection of machines but have otherwise, moved on. Currently doing 65816 on 64TASS and looking fwd to getting my 68040 based machine (linked above) in January.
    1 point
  26. I think Commodore lost its vision and went nuts. Tramiel at least had a vision (and almost by definition a vision is an official business direction that other people will disagree with). Tramiel's vision again was the C16 to be that Sinclair competitor. It seems to me though that the C64 was already a Sinclair "suppressor" by the latter 80s. The C64 was the right system at the right time to "clean up" the 80s: to wipe out early competition and then mop up on the cheap computer market later. We all know the future wasn't eight bit. Even the market knew it in the 80s.
    1 point
  27. I was very impressed on the youtube video of Matt, I have a question, is the current emulator capable to emulate the yahama chip, i mean, emulate the FM synthesis? Is there a demo in the downloads section that demonstrates this? Sven
    1 point
  28. Definitely. If you're new to FM synthesis, I too would recommend getting access to some FM synthesizer other than using assembly or C on the CX16. I haven't tried Deflemask, but from what I have seen in Matt's video, it seems to be a good fit for that.
    1 point
  29. @svenvandevelde: If you want to play with patches, I recommend using the instrument editor in Deflemask (I'm pretty sure they still offer the freeware version). FM instrument design is definitely something that's better done by getting an intuition and feel for it more than a left-brained understanding. The technical part can definitely guide your hand, but to me, it's one of those things that you're better off just playing with knobs and seeing what comes out. You can save instruments in Deflemask to its custom FM instrument format DMP. I've made a script to convert DMP into raw register byte writes for X16. All you have to do to use them is poke them into the YM in the proper order using a very simple algorithm: (pseudocode) ym_write(addr,data) { // ensure YM is not busy, then: poke $9FE0,addr // $9F40 for R39 poke $9FE1,data // $9F41 for R39 } patch_data[26] = x,x,x,x,x,x,x,x,x,x,.... // (the 26 bytes of patch data) addr = 0x20 + voiceID // voiceID = 0-7 i.e. which voice you're patching ym_write(addr,patch_data[0]) addr = 0x30 + voiceID for (i=1..25) { addr += 8 ym_write(addr,patch_data[i]) } Assuming voice 0, the bytes of the patch should be written to YM registers: 0x20, 0x38, 0x40, 0x48, 0x50, 0x58 ... 0xF0, 0xF8 I call this format "YMP" for YM Patch. One thing I've omitted from YMP that may or may not be an issue is the operator mask to use when keying notes for a patch. OPM format also records this information (DMP files do not) - not sure how often one may come across patches in the wild that don't use all 4 operators.... Let me know if you'd like me to post that conversion script - it's a tool in the suite I'm working on called zsound, which currently has a defined music data file format (ZSM), and includes an assembly-based playback library, and an import script to convert from VGM into ZSM. (It can convert OPN chip tunes as well as AY-3 and TI SN7xxxx PSG chips as well as YM2151). Once I get more of the intended core functionality done, I'm going to release the whole thing for the community's use, but for now, I'll post the patch conversion tool if you're interested. I believe that instrument creation represents the bulk of the complexity of the YM2151. If you start with patches that sound like what you want, then playing music on the YM can be much simpler than even on the PSG, as it's really nothing more than just spooling a sequence of note pitch values and keyUP/keyDN events.
    1 point
  30. I had the same plan, but LuLu had a SAVE30 coupon code for a 30% reduction, so I pulled the trigger last night. I don't know if it is still going or how much longer. In any case, it was like getting the UG free with purchase of PRG.
    1 point
  31. I pulled the trigger too but was also late so will be in the next year's batch. I am just starting to look into it more deeply though and haven't had much time with emulator so far but looking forward to it and hopefully have it side by side with Commander X16 and write some software for both platforms.
    1 point
  32. I'm in the US, and many other people are, so Happy Thanksgiving to all of you. Canadians, please accept this as a Happy Belated Thanksgiving. Other countries can take this as Happy Thursday if there isn't a belated or early Thanksgiving in their timeline.
    1 point
  33. I hope you have a great day, and to others that they had a good holiday. Leftovers is why I don't like Thanksgiving much - too many days of PTSD - "Post Turkey Stress Dining." I just buy a drumstick and it goes in one sitting. The deals on tech stuff is a reason to like the American holiday. Great offers and close enough to Xmas that I can usually justify an annual purchase. (Thanks again Apple!) Plus that American business make offers valid in Canada. It would be interesting to know what non North American countries get in terms of deals.
    1 point
  34. This is awesome! Thanks for the info @Scott Robison, I didn't even know this project existed. I downloaded the PDF's and have been skimming them, the memories, just fantastic. A great reproduction. I think sometime after the holidays, I may get a set printed, give it a bit more time for errors to be found and corrected. I would just love to have those manuals on my shelf.
    1 point
  35. We're actually doing ours on Tuesday (30th), becasue I had to work 12 hours on Thanksgiving. The joys of working in healthcare. Thanksgiving is probably my favorite holiday. I love spending the day at home with my family, making the huge meal, the smell of the food filling the house. The best part is eating so much you're in pain for the rest of t he day, but you don't care, becasue it's so good!. Oh, and leftovers! haha
    1 point
  36. I'm working on a development to optimize the memory management for the CX16, allowing to dynamically allocate and free memory space at run time in CX16 BANKED RAM (BRAM) and VERA RAM (VRAM). The heap manager is being built using the kickc compiler of @Jesper Gravgaard, and we are working together to optimize this development for a larger audience (later). The idea came while making my "space game", I really needed a mechanism to dynamically load and free memory in both RAM types on the fly at run time. The complete source code of the heap manager van be found here: https://gitlab.com/Flight_Control/kickc/-/blob/CX16_VERA/src/main/kc/lib/cx16-heap.c This heap manager now allows to dynamically load graphics (files) into BRAM and when not needed anymore, to dynamically free these graphics from memory. Typically such activities would happen when switching between "levels" during gameplay, or at certain transition moments. The heap manager has not implemented the logic to load the files, but a loader routine using CX16 kernal calls has been made, that uses the heap manager to dynamically allocate memory as graphics files are loaded. This allows me to design the graphics flexibly, specifying the file properties, and the heap manager will allocate the required memory at run time in memory. During gameplay or "on the fly", the heap manager covers the needed functionality to dynamically manage the limited memory space in VRAM, for tiles and sprites and other graphic objects. The heap manager allows to dynamicall allocate required memory in VRAM during gameplay, and free up VRAM memory when the space is not anymore needed, freeing up memory for new graphic objects to be allocated in VRAM, on the fly. On top, I've added CX16 library functions to copy memory between RAM, VRAM and BRAM. One such important function is to quickly copy memory from BRAM into VRAM. Typically this is used for sprites during gameplay. In other words, the heap manager allows me to load up the graphics from disk during transition moments, filling the 512/1024/1536/2048 banked memory space in the CX16, which is slow loading. But then, during gameplay, it allows me to quickly manage the VRAM memory space and copy graphics in and out from BRAM into VRAM on the fly. The CX16 heap manager has been made with the following requirements in mind: The heap manager needs a small code footprint, supporting both BRAM as VRAM dynamic memory allocations using the same code base, which is located in RAM. Programmers will only use the heap manager to allocate larger portions of memory. For smaller dynamic memory allocations, other methods are to be used (like arrays, vectors). Align the allocated memory with the BRAM BANKS or VRAM BANKS structure. No header information polluting the data. This is also very important to avoid VRAM having any header information! (We don't want sprite or bitmap info polluted with header blocks, do we...) Minimize the size of the headers, as large headers quickly will consume a lot of memory. Avoid memory fragmentation, which is resolved by coalescing the freed data blocks. Relatively fast, but not super fast. Speed for dynamic memory allocation is not an issue. For games, allocating and freeing memory would happen between paused moment. Use helper function(s) to address the memory, while traversing the memory space. Easy use for the programmer, and improve the code readability, through a well defined API. (Later) Allow the heap manager to be used by programmers using other languages, using an assembler library. The CX16 heap manager has taken the following design decisions: There are 16 memory segments that can handle the allocation of various data segments in CX16 BRAM and VERA VRAM. Allocated blocks are aligned to 8 bytes in BRAM and VRAM. This should not be a problem, s Header information is placed in BRAM, to avoid any HEAP dynamic allocated memory to be placed in CX16 MAIN RAM. So no dynamic memory is allocated in CX16 RAM before 0xA000. Use handles instead of direct pointers to memory locations. This is important, since CX16 memory in BRAM is banked, and VERA memory cannot be addressed directly anyway! This will also allow for memory compression or re-alloc later. It also avoids the programmers code to have direct pointers being used, instead, using handles, the pointers will be "indirect". This has a small performance impact, but greatly improves memory management flexibility. The header blocks are separated from the data blocks. This is important for VERA VRAM. Header information placed in VRAM would pollute the graphics!!! We don't want sprites set to be polluted with header information, do we? Hope that this development will insprire others. Please contact me or @Jesper Gravgaard if the heap manager is of interest to you. Note that this development is still work in progress and is evolving till i'm satisfied with the design of the overall API.
    1 point
  37. Yes ... "shift right six bits" is shift left two bits and treat the result as all being shifted down one byte. "Shift right another four bits" is ten bits total, so shift right two bits and treat the result as all being shifted down one byte. And "if you still have anything left, return to step 2" is 14 bits total, which is shift left two bits and treat the result as all being shifted down TWO bytes. I don't test to do 3, since the shifting has already been done, and since the target is to have a 16.8 result from a 16 bit dividend, so it makes more sense to simply go ahead and include it. 1/60 - [(1/64)+(1/1024)+(1/16,384)] ~= 4.07x10^(-6), or about 0.000407% discrepancy ... off by 4 parts in a million. That discrepancy should be imperceptible.
    1 point
  38. Yes - I think pricing may be a factor, according to the wikipedia article - https://en.wikipedia.org/wiki/Motorola_6809 I had the pleasure of using a SuperPet in the 80's and all the Waterloo languages - they had dual CPUs of a 6502 and the 6809.
    1 point
  39. As many companies have proven over time, you don't have to have the best product to gain the most traction and take control of the marketplace.
    1 point
  40. And today is perhaps the most American holiday: Black Friday. Try not to murder anyone while Christmas shopping! And if you work in retail in the US: stay strong!
    1 point
  41. @Scott Robison After watching the 8BG's latest video on PETSCII Robots makes me really want the 128 version now! Again, excellent work sir! Love the features, look, and dual display option. Honestly, I want the X16, Amiga 500, and C128 versions now. Just in case the random browser missed the video:
    1 point
  42. Hey! Author here I'm not a regular user of this forum but I just want to say thank you for recommending my channel. Staying motivated to keep producing videos is hard, but this keeps me going, so thank you Calculon!
    1 point
  43. It was always such a shame that the 6809 got paired so much with the 6847 which makes games look like the colour was vomited onto the screen (I presume there was some technical reason for those colours because no sane person would choose them voluntarilY). An 8Mhz 6809 (in FPGA) and Vera would be an awesome machine. Also it's enjoyable writing for that sort of CPU. Writing 6502 assembler you always feel you are fighting it.
    1 point
  44. To be fair, only one of those three exist as a computer maker, and for that company, making computers sometimes seems like it is more of a sideline to making smartphones. Edit: Oops! "PC maker"
    1 point
  45. He's been messing with PS/2 and USB in his last 3 or 4 videos. Pretty sure he will be able to solve this in 30 minutes or recommend a different, yet elegant approach. I wasn't joking when I suggested somebody get the guy that did the "C=key" on the line. It maps PS/2 to traditional Commodore style row/column scanning; in a worst case scenario, just get it over with using something that works even if it costs an additional $1.29 per unit.
    1 point
  46. Someone get Ben Eater on the phone!
    1 point
  47. Hrrrng... if I didn't have a day-job that I loved dearly, I would be all over both this and offering to help out with the kernal. I mean, I'm continuing to work on the emulator; albeit in my own fork that I haven't formally announced here, but has been named dropped here by others. Suddenly, so many things I want to add to my precious hobby time. And I've previously worked with 2-way communications in microcontrollers for various sensors, so adding a PS/2 communication routine here sounds like fun to me. I hope someone pops up who can help out with this.
    1 point
  48. Pretty modern meme, but still...
    1 point
  49. Pointers are, at the same time, the best and most terrifying thing about C. Here's my favorite measure of code quality:
    1 point
×
×
  • Create New...

Important Information

Please review our Terms of Use