Jump to content


  • Posts

  • Joined

  • Last visited

  • Days Won


Everything posted by Starsickle

  1. Wow. It's been over a year since my last update: So, since my last post, I've lost everything in a fire and have been homeless for almost a year. It sucks. A lot. I've been trying to do quite a lot - everything, in fact, but yeah... So: Retrotrek. I've recently started poking at getting back to where I was, but discovered the project was entering production. With funding being achieved in less than a few days, I'm very positive that my time can be spent on RetroTrek here on the X16 without any further need for C64 compatibility. I'm going to take my time, as there's a lot of tools I'd like and means for creating a full game with the chipset finalized, but I would love to try my hand at completing this game. I'm juggling a few projects and quite literally everything in life, but making a game like this is something I want to achieve for myself, so help and advice is always appreciated. I'm an ambitious guy, gameplay-wise, so I can only say I definitely want something more than what we played when we were kids.
  2. Very very happy and excited for this. As much as I'd like to have one of those (homelessness sucks!), I'd much rather have all the developers that have put a lot of time in - especially those in tool and kernel development - have theirs first. If there's any way I can help, I'd love to. I would like to ask for one thing, though. An easy way to assign banks of space and then reference them. LOCATE is a powerful tool, and so is DOS. What I'd absolutely love is control over sections of managed memory. You have the memory - you have all the memory! - but the tools to use it efficiently would be a great help. For sure - this has me turning my eye to Retrotrek again. Really can't wait to see efficient and easy methods of file IO to memory without smashing my head into memory segments.
  3. Oh man - how can I not take this as personal? Okay. I know what a Raspberry Pi is. I know what a FPGA is. If I wanted a Raspberry PI C64, I'd already have it - because it's already a product. The C64 is already out for about 130 bucks. https://www.amazon.com/dp/B08GMTJYXJ/ Again - I'd have fleeting interest in it because I'd likely make it into something else instead of use it as it came. If the X8 is a Crowdfunding bonus, I'd get it because it's something, but I'm here for the finished product. And yeah, It's a dream to be able to program old stuff but remain in the 21st century. I don't expect enough work to be done between compatibility and reality to eliminate the absolutely absurd artifacts of 1970's programming in light of the 21st century development environments and requirements. If the goal is to make a usable computer, I will insist resolving the lower levels of problems with BASIC v2 and the C64's low level systems is a critical bit of work. I know some here don't seem to have any problem with this, but I am absolutely sure you'd reach a wider audience and ensure lasting use and value of the product if, like providing a HDMI or a USB or SD card i/o, you do the same engineering work in the software side of things. We do not use computers the same way as we did in the late 70's and early 80's. Proof enough is the rapid evolution of all those middle soft-parts before DOS computers came into the norm. Software is not developed to completion and subsequently supported by a single guru with unlimited time in a garage, anymore. It is the exception now, not the rule. Waiting for manna from heaven is not how you get a killer app. You need a development environment and ecosystem with high level ease-of-use. The cuttthroat University CS department "Make-everything-as-arcane-as-possible" way is not the way of real life. I want the project to succeed at a wider level of appeal. I see the above as a critical part of it. There's already plenty of collector's items out there, as well as pretenders and emulators that are far cheaper and do the job - but they aren't real computers, anymore. I want the X16 to be more than a mantle-piece for the wide audience it's said to be intended for. The project being at a crossroads is perhaps the best thing that could happen to it. I gave it a serious shot, and unfortunately I came up empty. I don't have it in me to try again without serious improvements in the middling levels and in the ecosystem. I would LIKE to try again, but without the cookbook or the environment - it's just me messing around in pico on a university unix system. I want to complete projects in a timely and reliable manner. Nothing wrong with that. I don't feel like I'm barking up the wrong tree, here.
  4. I doubt it. It doesn't have a USB port. And it has a DISK DRIVE It is two thousand and twenty one. This is clearly a mantle-piece and not something to be used by a real person.
  5. I feel bad having missed this thread since last month. If this is a Sitdown, so to speak, then I would have to add my two cents... I am going to be very real, right now: I am not soldering this project together. If you wanna charge us us $25*8 hours markup, be my guest. It's only fair given the circumstances. Sadly, this violates one of the core missions of the project but let's be fair: The world simply will not allow this to be made cheaply, right now. Two hundred dollars for a complete version of the computer that's supposed to be a day-to-day usable computer is fine by me. I've spent as much on a Polish button box. It costs what it costs. I will say this, though: I am only buying the computer ONE TIME. If updates are made, it will have to be on the board I had bought, with the components I had. I have no problem buying addon cards or other devices (Kind of the exciting part, to be honest. Feels very retro to me.), but whatever you release to the public - I want that case and computer. I want that product. I'm only buying it once. I am either waiting a long time, or hoping the crowdfunding drive nets me something neat so I can support you for far less with some headway to getting the thing I really want. I want to add about the keyboard: The keyboard being a top end mechanical thing is way way way too much. I saw that keyboard - it's very pretty. That price, though! You absolutely need a cheaper solution, and I'm fine with anything that works on modern USB with a PS2 adapter. I have those laying around, at least. That would save money. So, how to get my money NOW? As for this X8: I'm going to be honest - If the X8 is companion to crowdfunding and is less than 50 bucks pledge? I would get it, but I'll say right now I have absolutely no use for a Raspberry Pi other than turning it into other hobby projects. How you fund the business venture (Be completely up front about the stretch goals - no use shorting yourself when it's obvious the costs need to be completely there.) will be important to getting this done. The X8 as Crowdfund Bait is fine enough, but I honestly don't know what I'd do with it. Even as a programmer, I'm a high level guy - I need BASIC, and I need a modern BASIC. All the work going into the kernel and ROMs is absolutely worth the time. I want that computer. The Computer. The whole thing. I am not soldering this thing together. I don't mind assembling components into the case or chips into sockets, but I absolutely do mind burning myself and doing a sloptastic job and destroying my computer with only a "Oh well, to the forums!" or "Oops! Oh well! Spend more money!" to say if I screw anything up. Nope. Do Not Want.
  6. Well, It kinda fits the way we have our computers right now, doesn't it? There's an Arithmetic CPU and a whole other computer inside our computer doing more specific sorts of computations. I'm not sure how good the 6502 would be at that, but I don't see why you could have it designed as OP. In my Morning-no-coffee head, I'd say the bottleneck would still be the rate of synchronization between the two for tasks. I'm not sure what it'd be really good for in the world of 8 bits... The previous discussion really centered around arranging the electrics of the memory spaces, but my gut tells me that anything that creates more complexity invites errors. Don't want to be negative about the discussion though - the other posters have brought up some challenges in design, and I'm trying to look at it from other angles.
  7. The marriage to backwards compatibility is directly at odds with current day Personal Computer Usage. I love the idea of maybe getting something put into a socket or expansion port - possibly with a daughterboard because that's retro as hell - but it's more important to make the computer work to the needs of its intended users, and...well...work at its base specifications first. Good Design will carry it forward after that. There's a reason there were so many new computers back then, and I think discussions like these really demonstrate it because we have such higher demands on our stuff now. Honestly - Why wouldn't I just get an Amiga hardware clone project, instead? (Or a raspberry pi with everything including the disk drive sounds) . Also - it's 2021 - I am not messing with Kickstart and Workbench the same way I did in the 90's. It was bad enough I didn't know if my disks worked or not - but my Amiga became unusable when my Kickstart 1.3 disk died. As we go forward over the next 40 years of PC history, we can see how standards, design, and completeness became more important for every new computer system right into the x86 and beyond.
  8. This would be better off like a Dual Core computer but with entire chips. XD Two 6502s, a ROM controller acting as the thread/task manager (HAAAHAHAHAHA) and for the awesome power of...6MHz.
  9. I've never heard of it, but took some time to check it out. I'd have to go back to the specifications for my personal desires: I want a computer I can regularly use. That's the fun of it. I'm fine with a 8-bit CPU. The Mega65 is using a modern FPGA to build the circuit logic of the 6502. Conceivably, it will run faster because everything is programmed into the FPGA. Digital outputs. I'm not a collector of old TVs and monitors. That means HDMI, USB, and SD card slots. SD card slots with programmatic support for file access. Easy to program - memory and optimization can come last after building a product. The Dire Problem of Nostalgia: I've been thinking a bit about this - and I would hate to admit this, but it's in my mind when I compare the machines: The compatibility issue with the original C64 or VIC-20 is the ultimate overcommitment, because the truth is that these machines were infants in terms of design, usability, and capability. What both projects have right now is a crisis of identity versus the needs in capability of its users. We simply expect more of our computers. I think that one would either design to make an old machine OR a new machine with the old machine's parts. In this, I'd favor the X16. I want to see the 6502. I want to see chips (Feel free to use modern RAM). I don't mind programming in some form of BASIC: The problem for me is that I know over 40 years of improvement have gone into computing, computers, and our use of computers. We've already had them in our lives, and so we expect more of them. I'm fairly sure the Mega65 is facing the same problem, and the proof of that is its extensive documentation, modes, switching, and memory management. A glance at Mega65 BASIC and the underlaying Assembly (I am bad at assembly) would make me probably prefer Mega65 programming at the moment. I keep making comparisons to SmileBASIC in terms of ease of use. (Honestly, if everything on SmileBASIC servers weren't implicitly copyleft, I'd be making BASIC games on the Switch right now.) The Mega65 looks like a complete computer. Ethernet port, HDMI port, SD card slots. It's only missing USB. Why does it not have a USB port? It's 2021. Everything is USB. Disk Drives? No. I am not going out to buy floppies in the year two thousand and twenty one. Just no. If I want a retrocomputer that works worse than my phone, I'll become an antique collector. In all, the Mega65 looks like junk, is probably extremely capable once literally everything is automatically managed or wrapped up, and will probably be a very capable computer....if it adds USB. The X16 currently is trying to reconcile backwards compatibility with modern programming convenience. I have no straight answer to this, but I just want it to succeed and be able to straightforwardly program without arcane trickery. As long as I can keep doing include and execute, the sky's the limit.
  10. Okay, so it's been some months - Disaster has not been mitigated, so where am I? Projects wise, I'm recovering. I'm going to be recovering. It's very sad. I've lost quite a lot. For THIS game, though - I am slowly re-piecing together the design of the game, but I'm definitely on hold until my foundation is a bit more solid. I want to make this game, I want to support this machine, but I would definitely need help making something within the constraints of the system. Since I'm up at 4AM today, I decided to empty my brain of RetroTrek design into a separate game, which will be powered by Javascript. So, what is it I need to do this game on the X16? Ability to jump between large bits of functional programming that WILL be documented. Ability to store tables of mixed pieces of information, or several tables of compressed, bitwise information. (I've done this, but I'm shaky at it. Sufficient Parity between the Emulator and target machine. Ability to manipulate file system from emulator. (This eluded me, but just assume my games are coming on SD card for the X16.) I can see there's progress in some spaces of development, but I haven't had time to read in detail. For the time being, I welcome examples of larger program structures and techniques, as I'm a high level guy with some big ideas on a small system.
  11. C IS the language of Atlantis, after all. Honestly, as long as whatever we get is well documented and follows the strictures of BASIC - Whether it's C64 Basic 2.0, or C64Basic2.0++ or Basic 7, or SmileBASIC, or BubbaBASIC, Grandma Tillerson's ButteryBASIC? I'm sure a well-documented, well-cookbooked community will adapt and be able to program for the machine. The real question is: is the backwards compatibility requirement in the specification a hill really worth dying on if the machine's ACTUAL specifications can't be used by its core audience (newbs and amateurs)? Everyone involved are very smart people, so I think it'll be worked out.
  12. Fantastic! If the kernel and interpreter team don't make progress, this tool would be a great optimization tool for people like me that have some large and sprawling ambitions.
  13. The fact that this CPU and The Vera board are so powerful and widely used means that there's a host of honest practical applications for this computer for any enthusiast. I don't plan on replacing OpenOffice on my desktop, but I could see - for FUN - writing code or notepad style documents on my X-16 and using a SD card to ferry files to my desktop. Or - sometime in the future - using whatever might be cooked up to replace the old C64 modems (and some nice software) to use the modern internet to send myself some files. That is what I would want as a user - a retrocomputer I could use for some set of practical purposes. Something that isn't just a nostalgic toy for an aging millennial. As a programmer and game developer, I really just want some sort of functionality close to something like SmileBASIC, perhaps with a bit of careful thought about optimization or feature-usage. Any efforts to allow users to easily use the larger memory and banking/swapping system is a worthy endeavor, otherwise I imagine myself starting a github and asking for help and maybe providing a lot of free coffee to helpful souls. For all those involved - please keep working hard, and keep aiming at continuous improvement.
  14. It's a HDD. I followed the vendor's guide to choosing, although their shop was quite a sprawl. As for github, I had considered making a private github for retrotrek but the project wasn't mature enough to warrant it anyways. I have the project tracker up, but no repo.
  15. There is some hope: I ordered a replacement PCB. An affordable waste if it doesn't work, but I believe I can do it myself. Needless to say, despite the small preparations I've made, I'm going to be more aggressive about backing up data.
  16. Disaster has Struck - A PSU incident has caused my Data HDD to stop responding completely, meaning it's effectively dead. A lot of recent projects since June have been busted, which means basically all of them. RetroTrek will have to be started over from Scratch, as I have lost even the Code, Design work, and Documentation. I am currently in Crisis Response Mode, but I have no doubt I will need at least a good hug in a few days.
  17. This is the majority of the block before the program handles its title screen input, after which it loads DATAINIT.PRG: 18 REM // DEPENDING ON GAME STATE: INIT DATA, MAIN LOOP, EXTRA, TERMINATE 29 REM //SETUP ENGINE, START GAME, MAIN LOOP, (TBD), END PROGRAM 20 IF CS%=0 THEN : CS%=1 21 ON CS% GOTO 25,1020,2000,9997,30000 22 GOTO 31110 25 REM //ENGINE SETUP AND INITIALIZATION===================================== 26 REM //NOTE: NEVER EVER OVERWRITE THESE! 27 CS%=0 : PL%=27 : REM //CONTROL STATE AND PREVIOUS LINE 28 VN$="0.0.1" : VD$="SEPTEMBER 14TH, 2020" 29 FC%=5 : BC%=0 : FI%=0 : BI%=5 : COLOR FC%, BC% 30 SX%=640 : SY%=480 : REM //SCREEN SIZE 31 DIM MSGQ$(20) : REM //OUTPUT SPAM QUEUE 32 QH=1 : QS=0 : REM //QUEUE HEAD, TAIL, AND STATUS 33 REM //===PROGRAM START========================================= 34 CLS : GOSUB 3120 35 LY%=43 : LX%=1 : GOSUB 1100 36 INPUT "PLEASE MAKE YOUR SELECTION"; MNU$ 37 GT$ = MNU$ 38 DEF FN FR(X)=FRE(0)-65536*(FRE(0)<0) : REM //COLLECT GARBAGE AND FREE BYTES 39 GOSUB 73 : POKE $30D,0 : POKE $30E,50 : SYS $FFF0 40 RF$ = STR$(FN FR(0)) 41 PRINT FN FR(0);"BYTES FREE" : GOSUB 70 42 REM //===PROGRAM DATA ALLOCATION================================= 43 DIM GD%(10) : REM //GAME DATA - SEE README. 44 DIM RGN$(9,19,2) : REM //SPACIAL REGION - SEE README. 45 REM DIM SCTR$(9,9,2) : REM //SPACIAL SECTOR - SEE README. 46 DIM SPCS%(7,5) : REM //SPECIES LIST - SEE README. 47 REM //DIM PLANETS$(13,3) : REM //CONTAINS PLANET NAME, TYPE, IFF 48 DIM SHPS%(10,16) : DIM SID$(10,2) : REM //SHIPS LIST AND SHIP NAME AND IFF 49 NS%=0 : GD%(1)=10 : GD%(0)=0 50 SU$="GRN" : REM //SHIP STATUS 51 GA$ = "*********************************************************" 52 GB$ = "* *" 58 CS%=2 59 GOTO 1000 DATAINIT.PRG is less than 100 lines with whitespace, but both creates DATA and shoves values into the various arrays. As reminder: check above image some posts up to see what is happening. A good but laborious experiment is if I were to change the line numbers of the DATAINIT.PRG program to never touch any of the numbers in the main file? What would happen? Would the string literals upon execution be restored?
  18. Yeah. I'm mystified. The main file clearly allocates more to memory in every regard than the data initialization file, so the explanation doesn't seem to fit. No matter what the case - I need to fix this, and I don't know how. Design wise, everything important is allocated, and if the program can't even correctly execute a random string literal after going back into main fail execution? I am clueless as to what to change or how to make this work.
  19. The good news: It works again. The game is playable again. The Bad news: I think only the DATA segment of memory is preserved between LOADs. So in this pic, you can see that some of the string literals did not survive, neither did any of the dimension-ed arrays before they were filled in the Data Initialization file. But...curiously: 3106 PRINT " RETROTREK - "VN$" STATUS: "SU$" RAM: "RF$ Of course, the debug output for ship data DID survive. Well, mostly. The IFFs did not survive, the ship names did not survive. Yikes. I happy the program can execute correctly, but now I have this new problem that defied expectations.
  20. Okay - this is an easy fix, then. I just cannot have a 0 state when this is first starting.
  21. Problem with the switch statement from earlier: 21 ON CS% GOTO 25,1500,2000,9997,30000 22 GOTO 31110 Presumably, you cannot initialize CS to 0 because once the file is loaded, CS is overwritten. but what happens right now is that the program slips through to 22 (Error). If 22 was not there, it slips to 25, which sets CS to 1, and eventually leads to a REDIM error. How do I use this correctly? Apparently the implicit 0 does not trigger 25...
  22. This is how I'm doing it. I have plans for a full color mode someday, but today is not that day. For now, I simply GOSUB to invert colors, but storing as 4 variables makes it more obvious what's happening. 10 FC%=5 : BC%=0 : FI%=0 : BI%=5 : COLOR FC%, BC% 70 REM //SUBROUTINE - SET COLORS TO STANDARD 71 COLOR FC%, BC% 72 RETURN 73 REM //SUBROUTINE - SET COLORS TO INVERTED 74 COLOR FI%, BI% 75 RETURN For me, important cursor positions for LOCATE are documented within each subroutine. What's more valuable - A REM line of documentation or N pairs of integer variables? You at least need the upperleft corner of each window you write characters in, right? Your MFD window is very large for something that is presenting options for the player. You have about 24 characters of room before an even border with the top windows. Split that window, and make the lower right a text spam message queue or a some window to present description or data. Perhaps a mode tracking variable for the menu state you are currently in, and after that just use "1110 GET A$: IF A$ = "" THEN 1110" and more to control the input handling immediately instead of risking errors. In UX thought - every action (even in error) the player takes should invoke some kind of feedback from the game - so that has to go someplace.
  • Create New...

Important Information

Please review our Terms of Use