I repair and upgrade retro 8-bit computers, PCs, laptops, and mobile devices. On this channel you can watch videos of repair work, mods and restorations, together with 6502 software development and the odd bit of guitar playing from time to time.
I had a TI-99/4A in the day and those joysticks are terrible. There were third-party outfits that made adapters that allowed Atari-compatible joysticks to be used on the TI. My father bought an adapter by WICO in 1984 because we went through three or four pairs of TI joysticks that kept breaking, not to mention the awful feel and the clumsy position of the fire button. Using a quality Atari-compatible joystick sure made a big difference.
If I'm following this correctly, the bad JED code is only an issue with DMA. Is there any way to work around this and not use DMA with a firmware update? Obviously that would cause a performance hit, but at least the cartridges would work. Or maybe a better solution would be to blacklist the JED version in the firmware and have it report a warning message on boot. I haven't followed all the details of the problem carefully enough to know, and it's likely not worth the effort on your end.
It initially seemed like a DMA issue, but I speculate later that it could simply be a CPU SRAM access issue. I think it's reasonable to entrust the designer with the task of figuring out what the problem actually is, however. I am disinclined to remove DMA SRAM to SRAM copies from the directory reader since reliance on DMA elsewhere in the software is not optional, and if the hardware cannot work sufficiently well to build an array of filenames, it will surely fail elsewhere and in similarly problematic ways. Older, more primitive versions of the loader did not leverage DMA when building the directory, however, and that fact simply encouraged lo-fi, high-noise commentators to conclude that the newer loader was buggy when in fact more extensive reliance on DMA simply exposed the instability of the system. It's also worth remembering that JED 2.3 caused - on video - the two identical SIDE 3.2 cartridges to not even get as far as running the loader and instead send the OS direct to the memory test. That last idea (blacklisting JED 2.3) is very appealing, however, and something I had already considered. :) But as you say... what is the bloody point? Thanks for the comment!
@@flashjazzcat A self-test might be generally useful if you can identify an easy way to do it and the most likely types of faults to look for. But likely not a top priority.
@@pfcrow It's surprisingly difficult to simulate the exact operating conditions present in the loader using a separate stand-alone stability testing tool. I have tried; I might even have such a tool lying around for SIDE3 which I produced during the pre-release phase. The problem is that the loader is simultaneously banking ROM code, calling the DMA engine, writing information to the SRAM on the cart, etc. It was explained to me at one point by Candle that a problematic development JED was exeriencing problems remaining synchronised to the bus during these kinds of interleaved operations (note: I summarise here and speak without tremendous technical insight). As you can imagine, this presents a very difficult environment when it comes to debugging, and I have spent (wasted) a disproportionalely large amount of time over the past five years being sent down blind-alleys searching for software bugs which - for the most part - did not exist and having to justify and prove the functionality of code which somehow works or doesn't work depending on the JED revision or Phi2 signal integrity on the host machine. Therefore the onus is always on me to 'prove' my code, which is especially ironic given how lax the testing has become on hardware and JED revisions. Meanwhile, my code long passed the forty-thousand lines of assembler mark (and is due for another big refactoring pass), while the VHDL represents one or two thousand lines of code, and once the board layout is done, it's done.
Completely understand you and support you. Haven’t updated my U1MB and SIDE3 for some time as it just works fine for me on my 600XL with no chips changed….
My opinion of Lotharek just sunk as I continue on this technical journey. Stunned and disappointed. Regression testing is a critical concept in software testing, and the ISTQB (International Software Testing Qualifications Board) provides a detailed explanation of it. Here’s an overview: Definition: Regression testing is the process of testing existing software applications to ensure that recent changes or additions have not negatively affected existing functionality. This is essential after bug fixes, enhancements, or other modifications. Purpose: • Detect defects: Identify any defects that may have been introduced inadvertently by changes in the code. • Ensure stability: Confirm that the software still performs as expected and that previously fixed bugs have not reappeared. • Verify functionality: Ensure that new changes have not disrupted the core functionality of the application. When to Perform Regression Testing: • After any code changes, including bug fixes, new features, and performance improvements. • During regular maintenance cycles. • As part of a continuous integration/continuous deployment (CI/CD) pipeline. Types of Regression Testing: 1. Corrective Regression Testing: Used when there is no change in the existing software and the test cases can be reused. 2. Progressive Regression Testing: Used when there are changes in the software, and new test cases need to be created. 3. Selective Regression Testing: Involves selecting a subset of the test suite that is relevant to the changes made. 4. Complete Regression Testing: Involves testing the entire system to check for regressions, often used when there are multiple changes. Approaches: • Manual Regression Testing: Testers manually execute test cases. This can be time-consuming but is useful for exploratory and ad-hoc testing. • Automated Regression Testing: Test cases are automated using testing tools, which is efficient for repetitive tasks and can be integrated into the CI/CD pipeline. Best Practices: • Maintain an updated test suite: Regularly update regression test cases to reflect changes in the software. • Prioritize test cases: Focus on critical functionalities that are most likely to be affected by changes. • Automate where possible: Use automated testing tools to save time and improve accuracy. • Use version control: Maintain versions of test cases and scripts to handle different software versions effectively. Tools for Regression Testing: Common tools used for regression testing include Selenium, QTP/UFT, JUnit, TestNG, and others that support automated testing and continuous integration. By understanding and implementing effective regression testing strategies, teams can ensure that their software remains stable and reliable even as it evolves.
1:03:41 lotherak comes across as a guy who likes to sail friction free without any regard for the reliance he has on the guy who built the software. My opinion mate but based on what I see with my two eyes that wide open. Come on Lotharek, take responsibility. Start talking with your software developer. Be humble man.
59:28 sorry but, you ‘noticed’?! Why weren’t you made aware of this by Lotharek? You have to discover this? Uff 1:01:40 oh my god. Not an ideal situation. Lotharek WTF bro!
The root cause appears to be hardware revisions made without communicating these changes to the software developer. To make matters worse, it seems the device is put on the market, leaving users to catch the bugs. That said, the transparency shown in addressing these issues is commendable and incredibly gracious.
Thank you. It certainly seemed to me - after days of careful editing and repeated full viewings prior to release - that unless the piece was viewed through a fog of indignation and annoyance, it would be impossible to reasonably argue with any of the points presented. The response which appeared shortly thereafter adopted the only possible strategy other than simply saying sorry and undertaking to fix the problem: namely, blame-shifting and choosing to ignore the fact that nothing was done about the problem for two months after I privately raised the alarm and provided a detailed diagnosis of the issue in mid-May.
21:50 I am up to here on your video but if the hardware (the 1MB) is being sold, somewhere by someone then it would be unreasonable for you to contend with those non out of the box configurations. I purchase all my Atari accessories and the like from Lotharek in Poland and never had an issue. I have an 800XL and a side3 and it works great. You need testers. It’s a basic requirement and you need users to test. Read the ISTQB syllabus it will tell you why. If the software developers name is on the device, or not, he must stay in the loop. This product 33:42 is defective. I won’t even get into EU consumer rights law that cover EU consumers for two years. On to other topics, waiting for external 1MB expansion for 800XL I have a lot of respect for the pain. If hardware is being modded the software developer must must must be made aware of it. All changes must be documented. Test before release.
Thanks for the balanced remarks. I think I made the illustrious reputation enjoyed by the Candle/Lotharek products absolutely clear, and that what we're observing here isn't calculated negligence, but simply the cumulative effect of cutting corners here and there and making a couple of unilateral YOLO decisions. Anyone can make a mistake in isolation, but the trend of perfunctory testing and the complete disregard of the lead software developer has represented an emerging pattern of behaviour since I first learned of the SRAM changes long after they had been enacted. In the context of consumer rights and what the customer is entitled to expect: the vendor has benefitted from the kind of expectation management I have voluntarily undertaken for the past four years concerning the mitigation of SIDE3 stability issues, such that it was more or less accepted that the host machine might require a 74F08 chip in order for the cartridge to work. But that's already a tenuous situation, and changing things such that the first-aid measures are no longer guaranteed to work means those previously carefully managed expectations are thrown straight out of the window. Test before release, as you say.
@@flashjazzcat Absolutely, I completely agree with you. As a software tester, I understand the challenges you faced. Despite not being the best among my peers, I can see that you did everything right under the circumstances. You worked hard for your customer, safeguarding their interests and your reputation, and made this issue public, which is commendable. The big lesson here is that even the smallest change can turn into a defect if not properly tested. Additionally, software and hardware developers must communicate any new requirements to each other in a documented manner. This ensures risks are assessed, and the necessary testing is conducted to prevent defects in user and functional requirements. Including a few external expert users can help identify issues early, allowing for prompt analysis and resolution. I sympathize with the customer whose hardware was affected. You diligently tried to resolve the issue and suspected a faulty chip, replacing it in the process. Unfortunately, this rendered the device non-functional. While this effort unintentionally damaged the product, your decision to cover the cost was incredibly noble. Although it felt somewhat unfair since the customer was not at fault, your commitment to resolving the issue and taking responsibility for the outcome was commendable. I plan to watch your video again to ensure I fully understand the situation. An honest conversation between hardware and software developers is crucial. This incident can provide valuable lessons to prevent similar occurrences in the future. From my perspective, experienced and hardworking developers who build fantastic products often face unexpected and disappointing results. These can cause customer dissatisfaction, have a negative economic impact, and necessitate expensive fixes. Your transparency in handling this situation builds trust, and I can't thank you enough for your candor.
@@buriedbits6027 Thank you for that excellent commentary. You clearly watched the video and understood it. The only point I need clarify is that replacement of the GoWin CPLD with a Lattice part was intended to facilitate JED flashing using existing tools (I didn't suspect the GoWin chip itself was faulty - I simply had no way of programming a GoWin CPLD). In any case, I suppose it was unrealistic for the vendor to watch the video and reach the same conclusions you did, but nevetheless I don't think a strong sense of obligation to the customer and to the product and development team needs to be in any way mututally exclusive, and if it is, something is seriously wrong and that's a situation I cannot possibly inhabit long-term.
That gowin FPGA is proably able to Run whole your computer inside of it... I dont get the point of this "cart" at all, it would me more practical, and proably even cheaper that this "card"... My 25 USD Tang nano 20K can run whole Atari ST with no problem at all (and you can run it on even cheaper 9K version)
You'd be surprised. The cartridge emulation logic consumes a large amount of the CPLD resources and there is little room left for anything else. The point of it, anyway, is to allow easy mounting of cartridge images of all conceivable types on a real computer, along with executable loading, hard disk functionality, etc. At the end of the day, there is no point in having any physical hardware whatsoever if you look at it that way, since I can emulate everything on the free-to-download Altirra emulator and experience everything in cycle-exact accuracy on my PC's monitor.
A .jed file (in this case) refers to a bitstream which is used to program an FPGA. The old .jed file for the Lattice fpga has absolutely no chance of working on the Gowin (unless the people at GoWin stole the Lattice IC chip masks and are making identical clones.) If you were somehow able to send up the old .jed file, at best the FPGA is bricked until the correct configuration is written ... but more than likely, there will be internal gates configured incorrectly, resulting in outputs connected to other outputs, and/or fpga pins which should be inputs, configured as outputs. In either case the FPGA probably self-destructs.
Yes, this became apparent as soon as I set the programming software up, which is fortunate since no-one thought to tell me beforehand that GoWin didn't use JED files and that I'd need the '.fs' bitstream, previously (in the case of version 1.3) produced from the Lattice VHDL sources compiled specifically for the GoWin CPLD. Then a few tense moments when it appeared that Candle had consigned GoWin JED 1.3 to the trash, before finally the file was produced, flashed, and the problem determinately fixed.
I have worked on a couple of projects porting stuff to those Gowin devices and I think I have an idea what's happened here. The Gowin chips have a somewhat unusual architecture because their logic blocks (which they call "CFUs") contain both logic and routing resources, so depending on the placement the fitter might have to route signals through multiple CFUs. This makes setting a long default maximum propagation delay and just assuming that it's always going to be much quicker than that (ok, it's bad practice - but it works pretty well on the Altera and Xilinx parts) a major problem because if you tell the fitter that this signal can tolerate lots of delay then it may well take you up on it and route it halfway across the chip. My guess is that the HDL had timing constraints that were either missing or too loose but worked anyway with the original FPGA.
These kinds of concerns definitely ring true concerning my prior conversations with Candle concerning the subtelties of CPLD signal routing and resources (not that I have much knowledge about it: I just asked because I was interested to know why the same VHDL can function differently depending on compilaton conditions, etc), but what's still puzzling here is how and why the older Lattice JED ported to the GoWin CPLD works well here while the newer JED tweaked specifically for the GoWin CPLD does not.
@@flashjazzcat It's hard to know - but my experience has been that even small changes can have drastic effects on the final routing, including significant changes to the timing parameters of signals that you haven't touched at all. This is generally true on FPGAs, but the distributed routing on the Gowin parts makes it even more apparent. Basically, if a signal has a timing constraint then you have to tell the fitter about it and it's unsafe to make any "it should be fast enough" assumptions, especially as you use more of the available logic capacity. The good thing is that in my experience the software does exactly what you tell it to do and if you have a fully constrained design it will perform as required.
@@TrimeshSZ That sounds absolutely right. I remember Candle would send me a Lattice JED, I'd test it, find it had issues, and then Candle would simply make some compile-time adjustment to the routing or resource usage and everything would magically work. It's exactly the nightmare I referenced in the video, though: if the hardware behaves indeterminately but the developer swears up and down that it 'must work', the software naturally becomes a suspect and it's possible to enter a death-spiral of software and hardware changes which actually end up making the situation worse. This is the exact reason that despite the known imperfections in Loader 0.69, core functionality has been exhaustively proven to work over the course of two years and it provides a baseline constant on the software side which is the bare minimum requirement while we diagnose these JED issues.
Yes. It took eight years for Rapidus to be discontinued, while it took only eight weeks for SIDE3 once I notified the vendor of issues. I suppose that's progress? :)
Watching this got me thinking. My SIDE3 3.0 is collecting dust for a while now, since it won't work with 0.69 driver on any of my machines. I downgraded JED from 1.3 to 1.1 and now it looks like it's working. Thanks! Lotharek stopped selling SIDE3!
That's great: I'm so glad a downgrade (from 1.3 o 1.1 in this case) worked for you, and thanks for reporting the outcome here. :) Doesn't thus just underline that there is already plenty of variance between the behaviour of the two prior (and reasonably well tested) JED revisions, without adding yet a third (poorly tested) JED (and on a different CPLD) into the mix! As for SIDE3 being withdrawn: while I think that's a sensible move in the short-term, I'd have liked to see it happen in mid-May when I first reported the issues to Lotharek in private rather than two months later when I had to report the issues in public. More concerning again is that Lotharek has withdrawn FJC-firmware U1MB boards from sale without bothering to give me advance notice that this was happening.
I suspected for some months that I was being goaded into a rage-quit. But it actually feels more like boiling frog syndrome at the moment, as one FJC-firmware device is withdrawn from sale, then two days later, another...
@@flashjazzcatmaybe you and candle can find another hardware assembler to work with. I bought a memory board for my atari 800 from reifsnyderb recently and it's clean.
I bought a SIDE3 years ago when I first got my hands on an 800XL. I also bought a U1MB and a VBXE -- *all* of them from Lotharek. He seemed like a pretty good guy at the time, and I would give him some repeat business when I got my hands on an Atari ST some time later, and have largely been pleased with what I purchased... That is, until I actually tried to install the VBXE. I should preface this next part by saying that I'm no slouch with a soldering iron. I grew up as the son of an electrical engineer and so soldering (and desoldering) was commonplace for me. I don't have the 60-plus years of experience my Dad has, but when he looks at my completed boards and routinely says, "Looks fabulous, just clean off your flux and you're good to go," I tend to think I actually know what I'm doing. What I got from the VBXE was glitchy video, inconsistent drop-outs and maddening levels of screen-scrambling that all stemmed back to two things: reliance on turned-pin sockets for DIP chips and an "adapter" that doesn't actually fit properly in a machine with my style of keyboard. I knew the adapter was the source of the issue when I could power the machine on and gently push on the ANTIC and get the screen to freak out. So I pulled it and everything worked fine. It's a shame, too, because I really wanted the VBXE to work so I could easily integrate the 800XL into my AV rack. I looked into trying to desolder the VBXE from its adapter and put it into a redesigned one that's lower profile and allows the ANTIC to mount *through* the adapter instead of stacking sockets. However, the adapter board seems as though it's been *deliberately* designed and laid out to make this all but impossible because you'll damage the paper-thin traces before you ever get the solder cleared from those header pins. It feels malicious, in retrospect. I don't know that I would ever recommend buying from him again unless he starts taking some responsibility for decisions that he deliberately appears to be making to put his personal stamp on designs and/or software that *don't belong to him.* As far as I can tell, all he does is *produce* the boards -- he isn't responsible for the hardware designs (that's Candle) and he DEFINITELY isn't responsible for any of the software (that's you). It makes me wonder what would happen if Candle decided to produce boards for his designs on his own.
All I can say - thank God I purchased two SIDE3's (and a batch of U1MBs) last year. And thanks Jon for your support to A8 community and excellent firmwares.
@@RowLikeaPro Possibly. I made an educated guess in the video that his test machines would have 64K SRAM and/or 'O2 Fixer' installed in them. I'll be interested to know if U1MB upsets anything. Maybe all one has to do is spend a further £30-50 to make these things work, LOL. :)
What about altera cpld? Epm570t and larger fpgas Downside is 3.3v level shifting needed I could throw and altera max ii, esp32, some sram, and SD card Don't really need a ROM, just an os handler (driver) and menu, can load that via Sio...
Ask lotharek how feasible it is to replace the ram in Atari with flash memory If the R/W cycles are under 100ns The Atari shouldn't tell it's non volatile Just need different boot init for the base 64k, and 512k page on top Then use the megabits above in place of the floppy drive Even modern flash chips still have parallel data modes And you don't need battery backup
I've watched this and Lotharek's answer. I'd like to start with that I love and apriciate what all three of You (Lotharek, Candle, FJC) do for the community. That said, I think you seem to have big communication and project management issue here. What we see here is a hobby project that grown and is not hobby anymore. What is obvious for me is that you need a project manager person to hold it all together. You need project management, release management and maybe more. I hope that all this problems will soon come to pass, and we'll soon see more incredible releases :D
Lotharek's response video (which I will rebut in the fullness of time) seems to completely miss the point. Not only that, but it contradicts Candle's point of view on a number of issues. Lotharek fails to mention that back in February (according to Candle), Candle repeatedly asked Lotharek to send me a copy of the new JED and a means of flashing it, so that I (as the author of the Loader and drivers) could test it prior to release. Not only did I receive nothing, but even after requesting the GoWin programming interface three months later when I first learned of JED 2.3's existence, I received nothing at all. So it seems to me that due process was advised by the author of the JED 2.3 (who was solicited into creating it) but simply not enacted. This negligence comprises the central complaint in my video. He also indicates that he 'heard nothing' for four months until my video was published, when in fact I raised the alarm bells concerning JED 2.3 on 17 May, two months before the video was released. While I agree that this is a project management issue, simply not excluding 1/3 of the three individuals involved does not require class-leading management skills or titanic intellectual capacity. Two or three Whatsapp messages and potentially one £25 GoWin dongle sent in the post would certainly have prevented the whole situation from occurring. Instead I was left in ignorance for three months and then left hanging for a further two months while attempting to sort the situation out myself. I suppose - given the fact Lotharek hilariously entertains the notion of recovering from me firmware commission paid on devices RMA'd because a poorly tested JED was released without my knowldge - I can whistle for the £130 I spent on a replacement cartridge and a GoWin platform dongle. Having spent two hours talking the matter through with Lotharek last night, and actually believing we understood one another and that he was determined to fix the issue, it's disappointing to say the least that he produced a 'statement' thereafter in which he lays out his plans to materially penalise me (and Candle) yet further.
@@flashjazzcat that is exactly why I think that some project management is needed here. Clear lines of communication. Clear separation of responsibilities. Release management. You (and that is a plural You) outgrew hobby level of doing things.
I think it's completely by accident, but it might well be the case. 'Never attribute to malice what can be attributed to incompetence', although since Lotharek is now inferring that he is considering materially penalising me (via recovery of firmware commission) for customer-returned cartridges RMA'd because of a poorly tested JED about which I knew nothing until three months after it was put on every production cart, malice might actually explain it.
Why didn't you just drill the hole and then use a TAP AND DIE set and thread the big piece of Metal inside the Camera that was there already? (LOL, I see somebody suggested it already)
You certainly won't be ordering SIDE3 from Lotharek now, since he's withdrawn it from sale, and done the same with the FJC-firmware U1MB for reasons completely unknown (stock version is still available).
Interesting Lotharek has suspended sales of the Side 3.2 with FJC firmware: SALES OF SIDE 3 is unfortunatelly supsended. in light of recent events and FJC video I AM NOT ABLE TO SUPPLY DEVICE with right FIRMWARE .... Awaits answer from Candle.....
That's the first competent thing he's done, albeit two months or five months late depending on how you look at it. Clearly there's a communication issue, since Candle believes Lotharek should test the JED while Lotharek believes it should have already been tested and proven fit for release by Candle. Or by me? But I'd have to be told it existed and sent a copy first, which Lotharek didn't seem to consider worth doing. I can't make it make sense no matter how I try to add it up.
I hope that these differences/disputes/problems can be worked out. I hate to see this. My Atari hobby gives me something to look forward to. I totally understand the frustration expressed, but we need the combination of the hardware availability, your excellent firmware, and support. We will all be in a mess if there is not a supplier of the hardware, support, and firmware. I hope that this does not become a wall that puts and end to great combinations of hardware and firmware for the end users.
I spoke to Lotharek in private for two hours on Wednesday evening and genuinely believed by the end that he was intent on making things right. Unfortunately in his recently published statement on RU-vid, Lotharek infers that he is considering penalising me yet further (over and above time, money and resources already invested) in a material sense. So it's hard to know whether I will be involved in any of these products at all going forward.
Entertaining video! I've bought quite a few things off Lotharek over the years and had no problems. I was thinking a getting a Side 3 for my Atari 65XE (upgraded to 130XE with VBXE). I think I'll hold off for now and stick with my SIO2SD. That Ultimate 1MB + Side 3 addon would be amazing, but will it ever be ready to be released. Doubtful ....
Imagine what fun it will be for me if I have to purchase more of the stuff for customers who want it in the future. I will be braced for issues every time the postman arrives.
@@flashjazzcat I feel your pain, Been a Dev my self. (Ok it C#, HTML5, CSS and Javascript) with a bit of DB thown in there. I agree with other comments made on the Video about needing a Project Manager to help sort this mess out.
@@darrenhunter2324 I'm coming round to that way of thinking more and more as well. The fact is, the 'coming soon' products I advertised in late 2022 have no development strategy that I am aware of, assuming they ever see the light of day at all. And here I am now with the two products which generate the bulk of my firmware revenue withdrawn from sale on an open-ended basis (and I wasn't even personally notified of their withdrawal), and no way of planning ahead regarding use of my time when it comes to firmware development (since I have no idea whether it will be needed and whether it will generate any further income).
Jon, the U1MB board you discuss in detail starting around minute 22 also seems to have some corrective hand soldering on the square chip underneath, at least under your filming light it occurs to me so.
U1MB is a steady seller, so I doubt that will ever be taken off the market. I see no likelihood of it being succeeded by it's external (PBI/ECI) counterpart, either - if that ever materialises.
Epic rant! I appreciate your investigations. Now I'm a bit worried because although I don't have a SIDE3, I have purchased other things from Lotharek that I haven't gotten around to installing. X my fingers they're not equally as botched. I'm now a bit gun-shy when it comes to his products. Very sad.
The customer isn't a beta tester...you have seen how Microsoft operates haven't you? Sorry about your frustration. I'm almost glad I can't find one of these things in the US.
LOL. Well, you make a good point, but I think there's a difference between the hardware and software side of things. At least Microsoft can issue fixes in the form of Windows Updates, and likewise I can release updates to the Loader which end users can apply without any specialised equipment whatsoever. And that's important, since the Loader is such a complex piece of software that I still have not fully implemented every feature I want to include (that's why the current release loader is versioned at 0.69). And I feel a strong obligation to 'finish' it, but how can I further improve the user experience if the hardware threatens to deny the user any experience at all? What we have here is more along the lines of an Intel CPU with an execution bug which can't be patched with an in-field microcode update.
@@michaelstoliker971 Haha. I managed to mangle the boot loader on a Windows 11 install the other month, but I usually have no problems. I have a dual-boot system, though, and I had somehow messed up the EFI folder.
Quite. That's why it's best not to jump to conclusions when testing. But this is the recommended SanDisk branded SD media, shown to work in all other cart revisions. And in point of fact, even a scrambled directory could not result in the kinds of errors seen here.
I'm glad I bought my SIDE3 3.1 upon release. When Candle mentioned to me on the AA forums that he doesn't believe in open source, alarm bells went off in my head regarding situations exactly like this. I understand that software and schematics should be kept close to one's chest, but JED files should be made available upon request in situations such as this - Better yet, 'situations such as this' shouldn't exist in the first place regarding the final product. Jon, your obvious passion regarding the product is exemplary. Every time I needed help regarding U1MB and SIDE3 on AA, you were always beyond helpful.
Thanks so much for the positive comments. What can I say other than that I think customers are entitled to after-sales assistance if they need it, and it seemed to me a wise investment of time to help them end up with a working system. IIRC, U1MB was initially intended to be effectively 'build it yourself if you want', but the situation became altered when the IP changed hands. And after that, we had the 'Pancake 1MB' board, which was a reverse-engineered U1MB clone which would have been quite useless had the developers (who lacked the ability to write their own CPLD code) not had access to the freely available JED binaries floating around on the Internet. There was also a SIDE2 clone. That situation clearly informed future policies regarding JED files on other devices, the fear presumably being that someone could reverse-engineer SIDE3 with relative ease, stick the JED on the CPLD, and start selling them. In any case: I think users are a little more forgiving of firmware issues on 'build it yourself' open-source hobbyist devices than on closed-source, commercially marketed hardware which supposedly sells with a warranty, regardless of the fact that everything under discussion exists under the 'hobbyist' umbrella to some extent.
The answer in which he fails to mention I told him of issues two months before I published the video, and fails to mention that Candle urged him to send me a copy of JED 2.3 and a means to flash it in February 2024, which would have circumvented the entire situation? Every single premise presented in my video - whose central complaints concern the lack of testing and the complete exclusion of yours truly - stands.
@@flashjazzcat Thank you for your answer, I didn't know about that. I think gentlemen, this failure has been made, and regardless of who is to blame, as an experienced engineer, I advise you to hold a meeting together to establish clear and inevitable development, testing and release procedures. Point by point - easy to understand and follow. Also - minimal test environments. This will certainly help avoid misunderstandings in the future. 99% of them always come from the assumption that something is obvious - NOTHING is obvious should be the rule :)
@@wieczor3000 Sensible advice. Let's see if there's any desire to move forward. Of course nothing should be taken for granted when changing firmware or hardware, or even when decreeing that such changes are needed.
Przemek doesn't seem to speak to anyone who dares to express any kind of criticism of his products. Also, he is a self-taught practitioner and is missing a theoretical background in electronics.
I suppose one can position oneself as 'just a salesman' or someone who considers himself to have sufficient technical insight to mandate fundamental changes to the hardware. Both situations cannot exist simultaneously.
doesnt work with u1mb correctly, doesnt work with usb power adapter, latest demo rewind 2 doesnt work - on other computers works.. somewhere something works, somewhere not.. :/
Man, I have 3 Atari 400s in various state of MOD ready for an Incognito Lite!!! Just sitting... 48K Gaming every other month... Waiting for an innocuous capability expansion... I probably need to sell two of them at this point...
I somehow have two or three 400s as well, one of which was donated for the specific purpose of Incognito Lite development. I doubt I'll actually use those machines without Incognito Lite and an aftermarket keyboard, for sure.
@@skywiseca I did start a rewrite a while back and commenced work on a 'NET' driver for SpartaDOS X, but simply got side-tracked with other things for the moment.
Wait 13:10 how are they programed in the first place? Do you use some other device with the chip NOT in the cartridge? I guess when they are mass produced they are programmed before they are soldered to the PCB and made into cartridges?
Your guess is as good as mine. I know the loader needed to be signed off before this production run started, but that's on the ROM chip. It looks like JED 2.3 was applied to the cartridges after the fact with a cable, however (they came from the factory with JED 1.3 on them).
I wish I could offer something to actually help here. I appreciate your passion for the Atari platform and community. The Ultimate 1MB / Incognito firmware is a work of art IMO. Thanks FJC.
I used to be a fan of Lotharek as I've bought many things from him, but that has soured over the last couple years. I bought his Medusa video scaler at launch and when it arrived it was damaged due to poor packaging. While it still worked fine, the case itself was badly dented in one corner. So I emailed him thinking it wouldn't be an issue. However after arguing with him why I accepted the package delivery if it was damaged (it was delivered to my UPS store mailbox so I never had a chance to decline delivery), he finally told me to ship it back to him in Poland and he would replace the case and ship it back. He wanted me to pay for shipping to him and he would pay return shipping. I asked instead if he could just ship a replacement case and I could install it. He said no. I insisted that that seemed wasteful and I didn't understand why I would need to cover return shipping costs. After that, he stopped responding to me. I sent him a couple follow up emails and he hasn't responded to any of them. So i refuse to do business with him directly and leery to even buy his stuff from resellers. The Atari 8bit computer scene badly needs other folks developing these addons rather lotharek being the single point of failure in this.
I'm sorry to hear you had a bad experience. I suppose the counter-argument offered would be that once the customer has dismantled the device, the warranty is potentially voided anyway, and the vendor is simply attempting to protect his interests, having perhaps been 'burned' in the past. But the most agreeable solution - as you say - is simply to ship a new case. Either way, I struggle to understand the need for adversarial email exchanges with customers (when any response is forthcoming at all). I was once threatened with small claims court by a client in whose machine I had installed VBXE when he decided he was unhappy with the picture quality. However, I managed to tamp that situation down and ten minutes later he was apologising to me for over-reacting. That was the only time in fifteen years of doing repairs and upgrades that things threatened to go south, but a little tact goes a long way. I actually ended up purchasing the machine back from that customer and finding that there was nothing wrong with it. Anyway: no matter whether I'm in a customer or 'partner' situation, the abrupt cessation of communications from Lotharek isn't exactly uncommon. I fully expect to receive plenty in the coming days, of course, despite the fact I was left hanging with the issues documented in the video for a period of weeks.
