wierd_w

Hmm.. I am unsure that my enclosure will properly hold a tipi+32k board. All the pictures I have seen, seem to suggest it has different screw hole patterns. I would need such a board to properly test fitting. EDIT Actually.. wait.. It's open hardware right? Is there a CAD model of the board?

I have started printing one for Omega. currently printing the bottom. So, @Omega-TI, I can embellish the top for you if you want. You always find some way to slip an omega symbol on your gear, I could do that right from the start. Say, something like this?

Looks good to me. If you have issues, name-drop me in the thread, and I will prod the font some more as needed.

No no, I mean straight up SDCard. Not CF. This is your typical "Sintechi" (ahem) card adapter. It does 2.5in style IDE, but a simple adapter makes it play nice. It does not want to share the channel, so keep that in mind. However, you can stick up to a 128gb SDCard in, and it will boot and run just like a CF offering. The cards play nicer in modern card readers. (it's even somewhat 'fast'. The one in my pentium box is able to do multiword DMA mode 2. However, it cannot do 48bit LBA, so nothing bigger than 128gb) The only issue I had, was that I had to do an fdisk /mbr on the drive/card before it would boot. I still strongly suggest the FastLynx option though, especially if you have lots of old retro dos systems to work with.

Other options: If you have a 'Tweener era system with a real LPT port, get yourself a copy of Fastlynx, and a suitable cable. Works like midnight commander. Fully browseable tree from either side, fully bi-directional transfers, easy peasy. Just a bit slow. You can bootstrap getting FastLynx onto the target system with MODE and CTTY, which should already be part of a DOS deployment. (or if not, easily fit on a floppy.) Also, SD->IDE adapters. I have one installed as the system drive of my recently assembled Pentium system. (Pentium 133, 128mb RAM, VX chipset). You can pull the card and manipulate it in a modern card reader.

That sounds like naked greed, in the face of clear and present inefficient pricing for product that does not meet the customer's actual needs. EG, "Why sell the customer what they actually need-- A mid-range system with decent performance and featureset, at a moderately increased pricepoint over the bargain floor offers, when we can forbid that option, and try to force them to all buy ferraris instead. Then we can focus only on ferraris, and make a killing." You see that kind of mindset all the way through to the late 90s, when the "Sub 500$ computers" hit the market, and then suddenly sold like hotcakes. Nobody wanted to specifically target the mid-range. They either wanted to target the "Toy computers for peanuts; they probably dont even know what they are buying anyway." end of things, or to target the "This is the sexiest bit of hardware out there, at the highest price, so you know it must be good-- We don't care that all you really need is something that can do spreadsheets in a reasonable amount of time; we are selling you something you can barely afford, that has more power than you need, because we dont want to diversify, and we know you have no choice, now open that wallet, and make it rain" end of things. The outliers to that were things like the early apple computers. Woz practically bent over backwards to drive the component counts down, and pricepoints down, as hard as was humanly possible for the time, to get as much bang for the buck spent as possible. (That did not stop Jobs trying to play silly games with the sales price, but it did show at least one of the founders was interested in getting the customer the balance between price and power that the market was actually demanding.) Slavish devotion to the "High or Low end-- there is no Midrange!" mantra is one of the reasons Commodore died, and did not properly manage the Amiga line of computers. They wanted to sell Amigas in the US as only high-end business machines, thinking that they could demand premium prices with an unbalanced price equilibrium. Meanwhile, in Europe, they realized that people were using them for a wide assortment of purposes, that they were widely popular as midrange home computers for gaming AND work outside of big-name video editing and pals-- and were busy trying to make and offer product to meet those market demands-- and the product did very well. I would say that the European example with Amiga vs the US one, clearly demonstrates that it was most certainly NOT about "We can't do that", so much as "we WONT do that", and the unwillingness to not do anything but the highest or lowest pricepoints, was literally toxic to the market.

yes, that is congruent with my (now) current understanding. The issue is that you want to use MOV, but your data is of an odd length. (and or, exists at a location that is an odd number, and thus straddles a word. Which only happens if a data element is an odd number of bytes somewhere in memory before it. In either case, padding it, and enforcing even alignment affords the speedup.) This can cause problems in at least two ways. First, if your source is not even aligned, then your reads will straddle a word boundary too, not just the destination. You would have to identify this, do a MOVB to read the bottom half of the word your data is straddling, then read your file out as if you had chopped the first byte off of it, at even aligned word boundaries until the end of the record using MOV. The second is if you are writing to a location that is not even aligned, in which you would have to do similar. These two conditions could be either-or, or BOTH at the same time. As such, you have to check for all 3 conditions, with the OTHER condition being straight up MOV only copy (because data at both source and destination are even aligned.) If this data is being read from a ROM, I would suggest a combination of padding in the ROM (to force even alignment), with a header or some other construct to know if the data was padded, so it can be treated properly. (Or better yet, require that your data format always be an even number of bytes.) With the padding already in the data structure, you can always trust that the data is even aligned, and not worry about it. The only issue would be to ensure that your initial program can determine if it has been loaded into an odd numbered address, pad itself to fix the alignment, then continue. I would think the best option would be to strive to assure that your data never is anything other than word boundary aligned from the beginning. Then you wouldn't have to invest instruction cycles on testing to see if it is not (because you can presume not, because you know exactly where cartridge memory is, and control how data is mapped there-- Assuming this is a ROM), and you wouldn't have to waste instruction cycles on wastefully slow copy operations that could run foul of compounding conditions of source, destination, or both not being word aligned, which could easily pile up if you are allowing data that does not meet the boundary alignment condition. I think the best solution is a combination of environmental sanitization at init (check only once at first execution if program was loaded outside of word alignment, then fix it if it was), followed by strict data type rules.

(I was being pulled literally 5 different directions when I was writing the prior post. Take that with some salt. I am home now, and no longer have such demands placed on me.) The intention was that you could pad your "Odd number of bytes" data with a preceding 1 byte pad, to make it even-aligned data. Then you can copy using only whole-word-copy operations. If you retain "even aligned with padding", and don't try to reclaim the RAM, you lose 1 byte for every odd lengthed data element. However, I was not contemplating that there is a restriction on the word vs memory situation. (EG, that the CPU addresses at the word level, so every single byte operation has to be chunked up and manipulated so that it correlates with a whole word being read or written.) Again, I was being literally pulled in 5 directions. This sadly, means you cannot use "odd address start" as a signal, since you have to write whole words at a time, with even alignment, to get the value-add of MOV. It might be better to have the data element itself contain a header specifying how large the element is, then back-pad to even length, artificially imposing even-alignment, and just waste the memory with the padding for the performance boost. (Unless I am mistaken again, and you totally CAN do a whole word operation in one cycle on an odd numbered location that straddles a word boundary. In which case, you can reclaim the padding by overwriting it on subsequent writes, and end up wasting only a single byte at the end of the chain.)

trust me, DOS is sufficiently retro to most kids these days. Especially when you throw in the obscure bits about memory management and pals, and the "slow" speed of the older generation processors. (sub 100mhz). The key point of the question is "JUST getting into." You WANT it to be familiar, but sufficiently alien to be alluring, and to coax them further down the rabbit hole. Going straight to the mad hatter and march haire is more accurate to the experience of entering wonderland, but you want them to have the table with the bottle that says DRINK ME first.

I get that. I am pointing out that it is not the showstopper you think it is. In case I am not good at explaining it, here's the basic gist: You want to copy a big block of data. Say something that is always either 511 bytes, or 512 bytes in size. (even or odd number of bytes, but still a lot of data.) This data lives in a ROM. When you master the ROM, you pre-place the 511 byte long elements on odd numbered addresses, and assure that there is a blank 00 byte just before it in the ROM. So, something like this: (addr) 00 01 02 03 04 ..... (out to end of element) -------------------------------- (Data) | 00 XX XX XX XX ..... (out to end of element) Your data index says the data rightly starts at 0001. which it does. It does because it is 511 bytes long, and is started at the first odd byte, per the artificially imposed convention. (which is how we know it is an odd number of bytes in the record.) However, the leading byte is (by virtue of your mastering process), preceded by an unallocated (not really part of any stream) 00 byte, which functions as the padding. Copying it has no real consequence, you initiate copy at 0000 instead of 0001, and grab the 00 byte along with the first byte of real data. This happens only one time. Since your destination is an odd numbered address, you will know that the data contains the padding, and can treat it accordingly when you use it in RAM. You could even reclaim the byte "wasted", if you were to use an actual even number in the address space preceding it for the next write. EG, your memory looks like this after you copy the first odd byte length record: E O E O E O E O E O E O E O E O 00 00 00 00 00 00 00 00 PP XX XX XX XX XX XX XX Then you copy the next odd length record into the space just before it, and overwrite the padding. E O E O E O E O E O E O E O E O PP YY YY YY YY YY YY YY YY XX XX XX XX XX XX XX Writing always starts at an odd type address. This lets you know that padding was used, and that you should ignore the first byte, and initiate copy from the preceding even byte, to use it as padding. Both operations use only MOVB. No RAM gets wasted, except at the last odd length record. (which occupies the highest order spot in the chain.) Properly implemented, you waste only a single byte of RAM to padding this way, and use only MOVB.

Maybe for the initial exchange of the copy.. Some simple rules to follow: Is total data length odd? If so, always select an odd numbered address. If address is odd, pad to make it even. (the same byte that makes the logical start address even, also pads the odd number of bytes to copy, making it even also.) This gives you two signals with one check-- If the address is odd, you immediately know: Data length is logically even, but actually odd, and padded by 1 byte at the start. This check need only be performed once. All subsequent parts of the duty loop are for whole words, since data size is guaranteed even divisible.

You are mistaking my statement (which was for 8bit micros in general), for being specific to CoCos. The TI99 for instance, piped the sound of the tape through by default, and was painful slow.

My unit is fully functional, and suits my needs. Unless somebody makes a "write on grom" based supercart mode for the thing, so that it truly can function as the only cartridge you will ever need-- I have no real reason to update the firmware. But others might have too strong of a tinkering impulse. Who am I to tell them they should not? Their hardware, their risk, their loss or gain. I just dont like being an early adopter.

The problems are (often) noise, and speed (especially without a fast loader). Many old 8bit micros would pipe the modulated tape sound out through the speakers. This was useful to know if the tape was janked up, not playing, etc--- but was not pleasing to the ears. Additionally, modern gamers are very spoiled when it comes to loading times. You have to get them acclimated to the loading times, and other warts of the ages of yore--- not throw them straight to the wolves.

I would personally suggest a 486, or early pentium system. People who are "brand new" to retro computing will have "Too alien an experience" going straight to an 8bit micro, since they will not have "First experienced the 8 bit way of doing things" like us old fossils did. The 486/early pentium era has 24bit color (in theory. 256 color in practice, but the pallet space for those 256 colors is 24bit), stereo sound, and decent-ish music generation. It is also not THAT expensive, and there is a FOCKHUGE game catalog. This makes it on par with modern pixel-art based titles that have become popular on mobile devices, so there is some familiarity that can be leveraged. This would get the prospective retrogamer some experience with the warts of old systems, and thus get them into a more experienced position to better grasp the 8bit world. THEN they could move to an Apple II, CoCo, or similar system, and not be quite so lost, confused, and ultimately turned off by the alien-ness of the experience.

This is probably very unhelpful, but-- If address location is ODD, pad first byte by 1, then treat as even. Then assume all reads and writes are even aligned. When working with the data, check if address is odd; if so, skip first byte, then proceed as if even. Just be wary of the dreaded off by 1, should somehow your check routines fail.

Colon and semicolon prodded. Font1Prodded.mag

yes, better. (A single pixel out of place can ruin how a glyph looks, so the mangling of the scaling routine makes it hard to judge if I have goofed up or not.) Fonts are real easy for me to do, but getting them "Just right" needs an "in application" test or two. (or three.) I also notice that the horizontal bar is missing from my font. (along the top of the status portion of the screen)-- is this an issue with the underline or hyphen character, or is there some other explanation?

Transposed letters fixed. (also, numeral 1 moved 1px to the right.) Font1Prodded.mag

The 1 needs to be bumped right at least 1px, it seems... Otherwise it looks pretty good I think. Always open to additional input on it. (And the distortion imposed by classic 99's scaling of the window hurts my brain.)

OK, I have prodded the font with the desired changes. Font1Prodded.mag

Maybe CTRL+SHIFT and numeric input, using a buffer? Similar to ALT+NUMBER used on IBM PC compatibles?

Hey, the font looks pretty good in 40col mode. Still needs prodding on the glyphs I mentioned.

I dont want you to be disappointed; I would suggest that you let me send a finished sample to somebody with a beige TI for better color matching and such first.

Alright-- The font will look a little inconsistent if I do that, but it should be doable. Sadly, I traded having descender space for having ascender space. (more glyphs need the headroom than need to be below the line.) Bitmapped fonts like this dont have the same degrees of freedom one gets with a vector font. I am limited by the hard restrictions of the EM window size. (and 5x5 is the smallest I can make a glyph and have it still be readable.) I have slept now; I will plug in the laptop and make some changes.