Jump to content

All Activity

This stream auto-updates     

  1. Today
  2. Just wondering (to the authors) whether you're amenable to (non-functional) changes to the code base such as adding comments to the ROM code (or even functional changes if it can be improved). I thought I'd have a look-see but soon realised that the actual commentary within many files is non-existent.
  3. Yeah, MSRP will rise on some goods I'm sure, so I don't expect everything to drop back to pre-craziness prices, but for what I'm interested in, it should still drop significantly compared to the height of the craziness. Gas I am not so sure on, only time will tell, but even that should still drop below $3 for what I use, regular. At least I hope. lol During all of this, I have spent more time on eBay than I have in years. It also makes me thankful I have a good paying job in a profession that's in no danger of disappearing.
  4. You could be right about gas, but I heard the same arguments made when the price of gas shot up to then record highs in June 2008 just to have them drop significantly by Christmas. I think prices will go down again, though it will be inflation adjusted.
  5. Pricing will never be the same. Hate to be Debbie downer but I just had this conversation (argument) w/my wife that Gasoline prices will never get below $4 (for super) again. Opportunism, market adjustment, greed. W/regard to ICs and any crap (or good thing) made in China... The way allies and adversaries are lining up, I can't see trade relations improving anytime soon. Once Intel opens their Columbus Ohio plant (in 5 years) we should have some relief. Until then (for those of us in the states), it's back to erector sets and fuzzy pumper barber shop for creative outlets. : )
  6. Yesterday
  7. My problem is with Jonathan Swift, who probably coined the term "inflammable" too.
  8. ... and the 6502's architecture of zero page addressing AND only having byte ADC and SBC arithmetic with "set up the carry bit, then start operating at the first byte and go as far as you want to go" makes starting at the little end a fairly natural choice. But if you don't realize that the 6502 is little endian, then "<" and ">" as "pointing to" the low or high byte respectively doesn't make sense.
  9. I guess I'm the odd one out I'm using 64tass. It's the cross assembler version of what used to be turbo assembler/ turbo macro pro on the C64 natively in the past. It has a few nice features that I make use of in the code generation backend of the Prog8 compiler. Like automatically rewriting branch statements into a jmp when the branch offset gets too large, or vice versa, and automatically eliminating unused code blocks. It does lack a "linker" step so can't be easily integrated with code coming from elsewhere.
  10. Yes, an advantage of G-Pascal is that Nick Gammon has already written it, and it was originally written to run in ROM on a 6502 board in the 70's, then ported to the Apple II and C64, so porting it to another 8bit system is a lot less challenging than porting a system originally designed for a larger system. And a tiny Pascal compiler for a bytecode VM fits a lot more easily in a ROM of an 8bit system than a native code compiler for a more complex language. Intrinsic to the design of the original Pascal was a syntax that supports single pass compilation.
  11. I pushed a new post, discussing BoxLambda's architecture, including an actual Block Diagram! https://epsilon537.github.io/boxlambda/architecture-first-draft/
  12. Another option is to combine an interpreter with inline assembly. An interpreter is much easier to bring up on a constrained device than a compiler. Here's uLisp for instance: http://www.ulisp.com/ On virtually all 8-bit home computer systems, that interpreter was BASIC obviously. I assume it was always and only BASIC because of the easy learning curve. But there do exist other options besides BASIC.
  13. Ender


    A while ago Michael moved the code for the "TEST" command there, which tests various BASIC commands used in SCREEN 128 mode.
  14. Nick Gammon's G-Pascal for Ben Eater's 6502 breadboard computer, based on G-Pascal for the C64 (if I understand correctly, because the C64 version was the one where he could find his old source code) is similar, with a bytecode "tiny" Pascal compiler (integers and chars, no sets or floats, but IIUC integers are 24 bit), assembler, simple line editor and command line shell, along with I/O code for connecting a serial UART via the 65C22 VIA: G-Pascal on Github, G-Pascal on Nick Gammon's site, 6502.org discusssion.
  15. Last week
  16. Since most of my X16 coding is in C using cc65, it's a given that I use cc65 for what little assembly I do.
  17. I've been using Kick Assembler which is a Java based assembler that is for the C64. Since the CX16 uses the C64 ROM, it has been fully compatible so far. It has a very nice macro language that makes things easier for beginners.
  18. UI REBUILD 08: REFUEL This is a late addition -- the ability to refuel from either the mainworld, or a local gas giant, or asteroid ice, or oort cloud ice. The latter two don't have "artwork" yet. The mainworld and gas giant are procedurally generated, and so are slow but not horribly so, and result in the same pattern given the same world data. Again, this screen would benefit from borders.
  19. UI REBUILD 07: SHIPYARD This is where you trade for another ship. This used to be a flat list, but instead I went to a page-flipping scheme where you see ALL of the stats for each ship on the entire page. It's great for when you need detail -- and when you're ship shopping I figure you need detail. HOWEVER... I started out with as much detail as I could fit into a 48 byte structure, in order to give me options. Now that I've filled up system RAM, I'm thinking there are some details which are not important. I'll have to think about that for a long time of course. One major thought I've had lately is that I shouldn't list a ship unless I have an icon for it. This limits my number of ships down to maybe 19 ships... maybe two dozen if I get a couple more designs squeezed in. I currently have maybe 46 ships, and I think there's sufficient overlap still, so this is probably OK. I have over a hundred unique ship designs on hand, but their differences aren't necessarily large enough to be important.
  20. UI REBUILD 06: THE HIRING HALL This bit works well, but has some problems. If I'm moving to borders, it needs borders. Needs a little prettying up. The colors are perhaps too muted. Maybe an icon would be nice here. The menu doesn't work like the others. I either need to use the standard menu system, or else make this one look and act more like the others.
  21. UI REBUILD 05: STARPORT The starport is where you repair and upgrade your ship. This needs to be more engaging, centered, nicer... right now it is a mess. I have no idea why I put the ship's data line at the top of the page, either. Most of that data has nothing to do with repair and upgrade.
  22. UI REBUILD 04: TRADE The trade menu is still fairly primitive... it's not centered, and the colors are too dark. Also, if I'm using borders, I need borders. I plan to use Tom's mockup as a guide for improving it.
  23. UI REBUILD 03: MAIN MENU This screen suffers from not really being anything other than a dumping ground for actions. It currently holds details of the source and destination systems, but it's not really an appropriate place for these data. It IS convenient to know that a destination is set, but I don't know if the full details are important here. Second, the current and destination worlds need to have borders, as does the alarm bar. Third, like Tom's mockup, I'd like the game's name on the page -- maybe at the bottom.
  24. UI REBUILD 02: ASTROGATION This will be the fourth re-imagining of the astrogation interface. My assumption is that a player would enjoy moving a reticle on a small piece of the big map. But, I'm not longer quite so convinced that it's a good idea. I also suspect it takes more main RAM than a list -- after all, there is placement code for the features of every system in the view. But I don't know if that's a major concern; I don't think it would make more than 1K difference. Here's the current view. And here's what I am thinking: If I keep this interactive map, then I need to center it, put a border around it, and find a reasonable way to represent the "metadata" on the left side. Replace the map with a short but expandable selection list (per Tom's suggestion), and include the current + destination system details in this view. I'm currently leaning towards #2.
  25. So funny story i bought the new atari vcs console. And i was a little underwhelmed with it as a gaming console its OS left alot to be desired... but it runs Linux very well. I actually currently work from home on my atari. Hahaha
  26. @Strider So in my bedroom i have a busted Chromebook behind my tv. Its running GalliumOS, and it connects to my tv via HDMI and i just have a SABRENT 4-Port USB 3.0 Hub that runs from the Chromebook under the tv and sitting right in front (I have it stuck to my entertainment stand with Velcro tape). I use a wireless keyboard mouse set that uses 1 dongle and i have the other ports for my different controllers. It does the job and the limited storage isnt such an issue since i mostly use it for retro gaming and video streaming.
  27. @TomXP411 The NUC is the one mini PC that actually sparked my interest when it was introduced, just not enough to make me want to invest in one. Now that I've actually had time to play around with this ZBox, I may very well look into getting one. I have no issues buying used on eBay, that's where this one came from. I'm thinking of getting one as an HTPC/Steam Link/Emulator replacement. @hardrockhero I did look at the chromeboxes, some were even cheaper than the ZBox. What stopped me is my unfamiliarity with them, not sure they could run what I wanted. Also, I wanted as much USB connectivity as I could get without using a hub. Lastly, I would want one that uses traditional SODIMM's and SSD storage that can be swapped or upgraded. I don't care of eMMC or running off SD cards on anything outside of a Pi3 or older. Still, for the price, one would be fun to play with.
  28. The discussion above is precisely why the META/L editor uses unique 4 character codes for each command, with the fourth character indicating the addressing mode. No ambiguity and no need to parse the parameter to figure out what the command is. And it's through my update to that editor that I was searching through ROM bank 08 and found some code that isn't in any of the documentation. Is that code an extension of CODEX?
  1. Load more activity
  • Create New...

Important Information

Please review our Terms of Use