Jump to content

All Activity

This stream auto-updates     

  1. Yesterday
  2. Great point @SlithyMatt. Honestly, I know this isn't some earth shattering find, and I really am not trying to make it into something bigger; It is a common machine and a later model TRS-80 Color Computer 1 for that matter. I am just curious if opinions differ. For instance, I am not a fan of Retro Brighting, but I would never begrudge someone doing it.
  3. Interesting vlog. I think it is a lot like comparing apples and oranges. The 6502 family had a smaller instruction set to be sure, but it was easier to remember the whole thing. An opcode byte was always an opcode byte, and the value of the byte didn't depend on the context as much. But certain things that were easy to do on Z80 were harder to do on 6502. As far as the difference between immediate and memory addressing, that's more an "accident" of the different syntax. One could just as easily write an assembler that just used a modified syntax for the 6502: "LDA #$42" could be "LDA $42" then "LDA $42" could be "LDA ($42)" Years of x86 actually lead me to prefer the alternative syntax. Using something like that for LDA, alternatives for the 65C02 addressing modes come out to something like: "LDA $42" "LDA [$42]" "LDA [$42+X]" "LDA [$42+Y]" (note: there is no zero page indexed by y, so it would be assembled as absolute indexed by y) "LDA [$4242]" "LDA [$4242+X]" "LDA [$4242+Y]" "LDA [[$42]]" "LDA [[$42+X]]" "LDA [[$42]+Y]" I personally like that (though it probably wouldn't gain great traction given its unfamiliarity to those familiar with traditional 6502 syntax) because it looks like memory addressing, and more levels of brackets are just more levels of indirection. As for the argument that the traditional indexed indirect isn't very useful, I think it can be incredibly useful. It might not be so useful in a Commodore or general purpose computer, but I can easily imagine it being used in some embedded application where a range of ZP is used to hold addresses to parallel arrays, and X can be used to select which array you want. Or ZP is used as a pointer stack to arguments being processed by a virtual stack machine. The biggest problem with this on legacy Commodore systems (I am not as familiar with Atari, Apple, etc) is the seemingly random use of ZP by the kernal and BASIC leaving very few ZP locations free for user applications.
  4. I don't think any of them are opposed to restoring common computers, like the C64 or Apple II. They are far more valuable in working operation. Something historic and rare like the Apple I would be a special case where it's too valuable as it is to modify, and nobody has one laying around that they want to get working again. That's why you see new PCB designs for making your own Apple I with off-the-shelf parts because nobody would dare tinker with a real one.
  5. In my newest vlog, I compare the ISAs of the 65C02 and Z80 to determine once and for all which classic 8-bit CPU is the GOAT!
  6. Thanks for your thoughts @TomXP411. I was doing some reading on this model last night, and from what I understand it can be loaded with an extended basic ROM and may, depending on the memory chips, be 64k. But the only way find out is open it up. Right now it isn't a priority. I have 2x 64k Color Computer 2, and have one modified with all the bells and whistles. Like I discussed it just blew me away because it looks to be untouched. I have never seen this before buying secondhand equipment. It was truly a shame that the corner was busted, it would be a museum piece then. I am working on a Toshiba T1000 right now, so I am going to put this one away and keep it in its virgin state. Maybe somewhere down the road. I was more curious as to how other feel in reguards to older equipment, and their opinions on modifying it to make it more modern. I mean some of us probably came here because we watch retro youtube channels. Most of these gents, modify, retro bright, rebuild etc.. I was just wondering if there are others who are strictly opposed to these practices. Thanks for everyone who has participated!
  7. Hi, i am Marcel from Germany. I love to code for Retrosystems :D Currently i work on an ESP32 SID-Player (own 6502 emulator-core with a basic and buggy CIA emulation). Hope the X16 will be ready soon :D Greetings, Marcel Cevani
  8. C64 color teaser video ready. Easy port, just updated a few addresses. My daughter say she still prefers the "green" version! https://www.youtube.com/watch?v=_mLAd9HJ56c
  9. Correct, I didn't literally mean colors, it was just an example. In a way, I think a "new Calculus" is needed - some uniform symbology for the common programming expressions (or whole patterns, if that makes sense). That was one of the pioneering thing of Isaac Newton: the development of the symbols of Calculus. I'm past nit-picking about syntax spacing (in code) and where my braces are, and abandoned Hungarian notation long ago (with occasional exceptions, as in everything). EDIT: To clarify, when I say "new Calculus" - not to replace existing Calculus, I meant borrowing that concept of a new symbol set that directly corresponds to typical Programming constructs (loops, branches, allocations, streams, ports, threads, etc.). Perhaps something in Simulink has this already, but I also mean a way to instrument/augment those symbols with additional meta-context-data ("applies to this platform or this build") and how those constructs map to the address-space, interact with thread-pools, etc.. Some set of icons (visual-floating in space, not 16x16 BMPs) could represent the very concept of "LOOP", "OPENING A PORT"(data stream), with virtual pipes show these data connections - many pipes begins to show the complexity, and also perhaps starts to show the excessive redundancies. It's how I see the code in my head, and I wish others could SEE that this program: it's a complex factory of manipulating bits. And I've coded long enough to know how good SDKs just "die" as certain key programmers retire. Code syntax is one thing, but a "worth money" programmer has invested in being proficient in key libraries to get stuff done. But when the tribal knowledge of that in-house library evaporates, yikes. It's daunting to inherit a 30 year old Ball-of-FORTRAN, but if the equations are still valid, what's the saying "don't throw the baby out with the bathwater"? But if all that logic could be presented in a standard set of virtualized icons - my virtual "Software Clockwork", maybe it becomes more approachable to future generations. Maybe. But perhaps just like ancient Monks - translating ancient text for centuries is just the way of things have to be for awhile. I'm not saying Latin/Pure Assembler is The Way, but I'm just saying we're struggling to move beyond High-Level Languages, to (more) cleanly abstract out Intent vs Efficient Clockwork (optimized opcodes) to invoke that intent. Speaking of optimizers, yes they are quite magical. But my mind is more about: how to make existing source more approachable to the-next-generation of caretakers. I can see a Programmers Keyboard, with our standard symbols - or however, to gesture up a FOR-LOOP, it's gonna manipulate 3-data cubes, and one of those cubes it going to get sent thru this pipe to a database.... Stuff like that: a Data Cube just being a visual virtualization of a STRUCT, but in that virtualization you can immediately see how it is memory-aligned, etc. (the corner of the Data Cube is some etched symbol indicating the platform -- immediately, not fiddling around with #define target settings).
  10. It is hard to know exactly what was edited in something of that length, but assuming you labelled the new parts as new parts: 1. Please don't color code as a primary metric that you expect to share with people. Some of us are color blind and we will snip the wrong wire and all will die. I understand the 95% or so of the population with "normal" color vision find color coding useful, but always always always provide other coding of data. When I started at my current job, orientation including information about various color flags in the parking lots where we were expected to gather in an emergency situation, the color being tied to the area of the facility in which you are assigned to work. When I made the observation that putting a letter or shape on there in addition to color would be really useful to about 5% of their employees (on average) I was told it wouldn't happen. Which is fine, just using it as an example that expecting color coding to be the exclusive metric that one uses to identify something is not good to a small but statistically significant portion of the population. I realize that you may not have been talking about literal color coding and were just using it as an example, but it was worth discussing anyway. 2. "Flight hours" is a useful metric. In my opportunities to interview candidates in the past, it has been my experience that people who code in their personal time yet do not have a degree are often better than those who have even advanced degrees but treat it solely as a job. There are exceptions, but that has been my observation. 3. Not a scrum fan myself. Agile is good, but Scrum seems to take certain parts of the Agile Manifesto and throws them in the garbage. And anything that makes work more like Star Trek has to be a good thing.
  11. Last week
  12. I've updated a few aspects of my manifesto to clarify a few points. Thanks for allowing the EDITS. But my favorite part is the very end: the notion of using the Star Trek Bridge as a replacement for SCRUM I'd like some college kids to give that study a try. But I must face the reality of what we've learned during the Ada Experiment, or the Jobs NeXT project, or maybe even LISP (?) - as great as they are, mass adoption of any new system is a really hard thing at this point. Without Academia support, it's a struggle. Maybe things are different these days thanks to the "Inter-Webs" Make it flashy enough and maybe anything is possible. While programmers tend to be introverts, the hallmark of a good team is they can get stuff done by just reading each other and NOT talking (much) [ my opinion of course, YMMV - but nothing is more distracting than a bored peer with apparently no code to write, and becomes a Chatty-Kathy about the weather, while you're doing Code-Surgery ] Cyber: thanks for the link, brings a tear to my eye. Not Understood indeed.
  13. Oh yes, I do think the P2 could be useful for expansions. It can handle /much/ faster than an 8MHz bus. It's been demoed to do 100MHz+ XSPI (Interfacing with HyperRAM in this case) and similar just fine on one cog. It does feel very overkill, but it may have some interesting applications.
  14. That's basically because I don't really know how to use the assembler (at least not yet), so I just went for the default program declaration the feels natural to me. It's at least 30 years ago since I last touched assembly language (and that was on M68000 systems). So I'm more or less starting over from scratch and haven't really gotten to the the more assembler manual yet. I have started reading up on the 6802 instruction set though. Not too hard to get a basic grasp of that given the small instruction set.
  15. I don't think these computers were special enough to be particularly valuable intact. Like the VIC-20 they competed with, there were millions of these computers out there. Even a NIB isn't going to be anything special. I'd do exactly what you were planning to do: perform the video mod and the other upgrades, knowing that you have a very good quality starting point and that this machine will look exellent after the modifications are complete.
  16. oh-- that's a somewhat simpler issue you're referring to now. What about tagging the actual variable declaration instead in prog8? Something like: volatile ubyte testvar or shared ubyte testvar to indicate to the compiler that testvar is used elsewhere that it doesn't know about? However, the question is: why would you even declare the variable in prog8 if your only use of it is inside an assembly block and not in any prog8 code (in this case, why not just define the variable inside the assembly block...)?
  17. I recently acquired a TRS-80 Color Computer 1, sight unseen from Goodwill, and something happened that I normally don't even think about with retro systems; it is in unused condition. I couldn't believe it!! Now it does have a cracked corner because it looks like someone dropped it, but other than that, it doesn't look used at all. Normally, I would tear into it, pull out the capacitors, modify the the output video for s-video, add an amplifier and sound output, upgrade keyboard, etc.. However, and I don't normally care, should I modify something so obviously unused? For God sake the warranty sticker is intact. Anyway, if you feel like letting me know your thoughts, I have included a little a poll. Thanks, and have a great day all!
    I really love this! Great graphical style to it and silky smooth!
  18. Right, I wasn't talking about the X16 specifically, just the 65C02 in general. I'm sure a clever person could probably find a way to create some useful utility with overlapping pointers (much as the BIT instruction is used to change the following instruction in some cases), but in general, you are only going to get 128 distinct pointers in zero page at one time. Yes, this is what I meant (except for the X16 specific portion of addresses 0 & 1 being used for banking, which I was ignoring for the general applicability to the 65C02, or really anything in the 6502 family).
  19. While there may be 253 possible locations for pointers, overlapping locations can't be used at the same time. Therefore, there are only around 127 pointers usable at one time.
  20. Actually there's more than that available. The location doesn't need to be an even number. The only ones you can't use are 00 and 01 (because that's allocated for memory paging) and FF (because the next byte isn't on zero page, although that still may work, haven't tried it). So there's either 253 or 254 possible locations.
  21. Let me again state that this is probably a very minmal problem and it could be covered by expanding the documentation for asmsub a bit. However, if you would like to add it to the compiler I suggest adding it to the asmsub declaration. asmsub get_low(ubyte value @A) uses (testvar) clobbers(Y) -> ubyte @A { %asm {{ sta testvar lda #$0F and testvar tay lda tbl,y rts }} I.e uses (testvar) (or something similar) just lets the compiler know that testvar is no longer a potential unused variable, even if there is no actual use in the assembly code. I assume you are parsing this line anyway to match call parameters.
  22. Guys, so many interesting thoughts that resonate in my head! Thank you! Related subject is rised in upcoming Massage Not Understood Film https://www.messagenotunderstood.com Check out trailer.
  23. that is actually a problem I haven't thought about yet! It would be very hard to let the compiler check your assembly code for invalid usages of the ZP addresses it allocated..... are you suggesting a dump of some sort of the zp locations it allocated? So that you can act on that manually?
  24. OK, $1000 is a number right from the start (for X16) and not a string as with Applesoft ! I get it now, Thanks
  25. I basically assumed that it would be fine to use ZP_SCRATCH variables as long as I avoided calling any subroutines "In between" use. That seem to be correct then. BTW, the main problem with using the various zero page location is that we won't know which are used by the code until after compile is done. Note that this isn't likely an especially serious challenge but it's sort of would belong in a block similar to "clobbers" (i.e that the compiler marks variable as "used" if it's listed for the asmsub).
  26. "Is there a way to indicate that a variable is in use in a asmsub? " There is currently no one great way to do that. There are a few work arounds though: You can force the compiler to output the variable by adding a 'dummy' assignment to it so that it is flagged as used: ubyte tmpvar tmpvar = 0 This will generate some code for that assignment obviously but it's just 2 instructions. You could use "%option force_output" in the block, but this prevents optimization for all other unused variables and subroutines in that block as well. Finally if it's just a variable you use in the assembly code (and it needs no interfacing with prog8 code) you can use any standard assembly mechanism you like in the asm block for defining variables: use free zero page locations, use cx16.r0 .... cx16.r15, use " tmpvar .byte 0", etc. Those handful of ZP_SCRATCH variables you discovered can be used too if you know what you're doing -- they often are destroyed if you call prog8 assembly library routines.
  1. Load more activity
  • Create New...

Important Information

Please review our Terms of Use