areeve
-
Posts
41 -
Joined
-
Last visited
Content Type
Profiles
Forums
Blogs
Gallery
Events
Store
Posts posted by areeve
-
-
I broke out my VIC-20 for the first time as I work through testing out my collection and boot up looks odd to me (picture attached from my phone camera). As you can see the characters are interspersed with blue and red ones and they should be all the same color (preferably blue characters on a white background). It's seemingly random as to what color a given character will be (e.g. whether a character is blue or red varies every time I start the system). I was hoping someone with more VIC-20 knowledge that I have might be able to suggest what might be wrong. My inclination is video memory, but it'd be nice to get a second (more knowledgeable) opinion.
- Thanks, Alan
P.S. It was having problems in that sometimes it wouldn't boot (just a black screen), but after a recap that seems to be resolved.
-
I have an Atari ROM cartridge that does not work (Thunderground from SEGA). After a cleaning my next step is to check all the contacts and then the ROM chip. So far everything checks out. It has a 2732 EPROM in it, but oddly it has no circuitry to invert the chip select. I have double checked the EPROM using another cartridge with the CS inverted and that worked too. My questions... a) Can I not just tie A12 to ground for the chip select to be active? b) If not then this seems like it could never have worked? The board has notches that fit the case perfectly and I got this cartridge like 20 years ago before there would have been any real reason to counterfeit... any ideas?
Thanks in advance for any help.
-
8 hours ago, tmop69 said:
I think you have now solved the problem, anyway it seems that you used an old "boot.rom"/"tiroms.bin" created previously the disk support addition. So the Disk ROM was not added...
In the "ReadMe.txt" file in the latest pack I've specified that it now contains console GROM+ROM+SPEECH ROM+DISK ROM. Moreover, I've recreated all the "FULL ROM" images of SSS that are requiring/using the disk.
This is indicated in the suffix. E.g. "[PROGR] TI Extended Basic v110 (1981)(Texas Instruments)[PHM 3026]_FULL-ROM+DISK+SPEECH.bin" means that you can load it as full image (option C in the MiSTer menu) and has, in addition to GROM+ROM of XB, also the SPEECH and DISK. This to speedup/semplify the use of the core (of course based on my personal experience).
In the next pack (I should release it soon) I've added some more detailed instructions on how to load disk with EA, to help in particular those who haven't used/owned a TI99. Of course, if you need help just ask here or on the MiSTer forum in the TI99 thread.Just to be clear, that was not the issue and was actually why this is so confusing. Getting the proper boot.rom is what allowed me to get a directory (catalog) of files in Disk Manager and load/save BASIC programs in TI BASIC in the first place. That made it seem like I had what was needed to support loading everything from disk so I figured I could load the EA ROM and then load EA 3/5 programs... apparently not. Apparently I needed an EA ROM with disk controller support in it. I'm still trying to learn about the TI's funky architecture and hopefully one day I'll pull my TI and PEB out and experiment with them (and hopefully they'll still work ?).
Thanks against to those that guided me through resolving this issue. I doubt I'd have figured it out solo any time soon.
-
4 hours ago, arcadeshopper said:
Ok if you have the latest files from Ciro you should see one that includes the disk controller with the ea cart do you have that
Sent from my LM-V600 using Tapatalk
Thank you! That was my issue and lack of understanding (well, still don't really understand the why, but I'll have to read up on that). It's so nice to see disk loading working here. (And thanks for responding before I spent time setting up a new MiSTer install for no reason!)
-
1
-
-
24 minutes ago, arcadeshopper said:
you have to load the EA with disk controller image to use it with the disk controller
I *thought* having the disk controller meant I needed the boot rom with disk.bin in it. Can you clarify what 'loading the EA with the disk controller image' means in more of a step by step? I am currently
1) Select the TI core
2) From the OSD choose load full ROM to load the EA ROM
3) From the OSD select a .dsk image for drive 1
4) Select 2 from the TI menu to run the EA
5) Select option 3 or 5 from the EA menu to run a program from the disk
If I'm missing a step (or two or three...) I'd be grateful if you could share specifically what I need to do for said step(s).
-
1
-
-
On 9/17/2021 at 12:34 PM, tmop69 said:
The disk must be SSSD (90K) or DSSD format (180K). I've tried several disks with MiSTer TI99 core without any problem (with EA, MM, XB, etc.). Try to download my MiSTer TI99 MegaPack V3.0 (MiSTer TI99 MegaPack V3) and try again with the disks in it, they'll should all working fine.
Probably some of the disks from whtech are PC99 360K disk, so you should read the directory with Disk Manager, but cannot load them correctly.
I tried images from the MegaPack and get the same result.... error 0 when I try to load them from the EA ROM. I am using ROMs from the MegaPack for EA, XB... etc so I have to think those are good (I questioned whether perhaps I had a bad ROM for the EA?). In addition to not being able to load EA programs, XB programs fail to autoload. It would seem I can start with the Disk Manager (1, 2, or 3) and get dirs (catalogs) of as many disks as I want and I can use TI BASIC and load/save to disk just fine, but as soon as I load a full ROM such as EA, XB, or something else then disk support dies for me meaning to EA option 3/5 gives me an error 0 (and XB also does not autoload) and I have to Reset to get the little disk support I have working again. I'm pulling my hair out trying to get this to work. I even tried my other MiSTer in case it was some obscure hardware error. The only other thing I can think of is starting with a fresh SD install so that's up next.
-
28 minutes ago, Shift838 said:
Probably need to convert the PC99 disk if they are that to V9T9 disk image.
Thanks for the quick responses... yes, both images are 90k (92,160 bytes) which matches the length of my TI99dir created image. As I'm not familiar with either PC99 or theV9t9 .dsk image format I can't say for sure, but after looking at both in a hex editor the headers, at least, look similar. I've attached the two images in ? if there's any interest in looking at them.
In the meantime I'll try some images from the MegaPack.
- Thanks, Alan
-
I am hoping someone can help me as I attempt to document TI floppy disk usage in the MiSTer Manual (https://github.com/adreeve/MiSTerManual/).
I was able to create a blank TI disk image using TI99Dir and load/save a BASIC program created in TI BASIC, but am unable to load games from the Editor/Assembler cartridge. I have several disk images from whtech.com and I am able to get a directory of the files on the disk using the Disk Manager software, but when I try to load/run programs from said disk I get an Error 0. At that point if I return to the EA cartridge then it can no longer perform a directory function on the disk.
Any ideas as to what I might be doing incorrectly? Thanks in advance.
-
1 hour ago, Stephen said:
Yeah - but even unloaded, a 7805 should not output 13V. That's the point of using a regulator (7805) in the first place, right?
The reading isn't coming from the 7805... as above I removed that and got the same reading. The reading is coming from across the resistor that bypasses the 7805 and is high (on the schematic that is also above), apparently, because of a lack of a load... but we're getting a bit beyond my 'learner' understanding of all this. I guess it sounds like my power supply is fine, though and I need to start digging into the main board and what's going on over there.
-
Actually I am wrong about the resistor... it's just such a low value resistor at 33 ohms this it passes the continuity test on my meter. So I guess we're saying that reading +13v on the +5v line is normal? I'm just plain puzzled by this.
-
As I'm having issues that this thread deals with I'll throw out that the schematic appears to be labeled incorrectly... the R203 in the schematic that is discussed here is really R202 on the actual power supply board (the real R203 as labeled on the power supply board is close to the bottom middle of the schematic). After doing a 48k memory upgrade and a recap my 400 went to the familiar blue memo pad screen (just blank) and then the system died (power light went out / black screen). In diagnosing I discovered that the +5v from the 7805 was really +13v. My first suspect was the voltage regulator so I pulled that off and it's fine. I then tested the board without it and was still getting +13v on the (empty) output through hole where the 7805 was which is when I noted the resistor could be one culprit. In circuit it was a short so I pulled it to verify and it's a short alright...
Thanks for the info on its purpose. I'm still not clear on why I'd expect a +13v reading from a multimeter. We're not saying that if I check the SIO +5v pin that I'd see anything other than +5v are we?
My concern is what other damage might have occurred as part of this fault ?
-
I'd like an Eclaire XL too if/when they become available again.
-
I am considering reformatting it, want to make sure I have the latest stuff. There have been quite a few discoveries in the years since it was made (I am thinking of the breakthroughs around the Tutorvision, Keyboard Component, etc.). Those who are reading this thread, can you suggest stuff that should go in an update?
Thanks.
I have a printed copy of a 1.0 version of the FAQ dated Feb 15, 1995. I'm trying to digitize everything to take less space and was looking for a digital copy... all I can find is 0.7 so I need to scan it. If you want a copy of my scan let me know.
-
2
-
-
I'm in for 1 please.
- Thanks, Alan
-
1
-
-
I see a couple things in this thread I can comment on (disclaimer: based on my memory) so I will... hopefully it helps someone:
The Rat from Zobian Controls was mentioned earlier. That was a piece of junk. It was basically a Tandy/Radio Shack Analog Mouse adapted to work with an Atari via the X/Y POTS (e.g. pair of paddle controllers). The problem was jumpiness in the signal. I tried to add support for our Business Manager software adding a little graphical menu selection up front (6 images that one could point to and click to launch that part of the software) via The Rat. I experimented with as many ideas as my 15 year old brain could devise, but could never get it to work particularly well to solve the jitter issue. Consequently the Rat didn't really go anywhere. I can't imagine Matthew Zobian ever made any money off of it after paying for those color ads in Antic magazine.
The Atari ST mouse uses the 4 joystick pins (up/down/left/right) to send its signal to an Atari in pairs for the X/Y axis. Basically (don't recall exactly) one might see 0, 2, 1, 3 if going up and 3, 1, 2, 0 if going down on the two bits being used for a given axis. The challenge there was reading the data fast enough. I added a bunch of DLIs to sample the joystick and then would process the data in between every frame. I think David Sullivan mentioned using the PIA interrupt or something so he may have had a better/more efficient technique than did I for all I know. In a nutshell, 2 bits for X and 2 bits for Y was how that worked.
-
Actually it was the SD Card. I had to format with https://www.sdcard.org/downloads/formatter_4/index.htmlinstead of Windows... copied all the data off of it, did a Quick Format with that Utility, and then copied everything back. It makes more sense that the Firmware doesn't like the SD Card data... now I can actually select an .ATR file.
Still not working so apparently I need to recheck my soldering (and now that I have printed a case I can do a better job of measuring everything), but getting closer...
- Thanks, Alan
I can confirm that if you hook the diode up to the Receive line vs the Transmit line that it won't work. :-) Mine's working now. Yay!
-
3
-
-
Just following up on my issue where I could calibrate the touch screen, but then could not access any of the menu options. Fortunately when I ordered parts from Ali Express I ordered 2 of each. I flashed the other board and tried it with the same touch screen before doing any soldering... same result... so I tried my other touch screen and that works great. I apparently have a defective screen. Why it lets me calibrate and nothing else is a mystery I am not going to solve (???) and if that didn't happen with my first one I'd probably have had more confidence in everything.
Looking forward to trying it with my Atari computer later.
- Thanks, Alan
Actually it was the SD Card. I had to format with https://www.sdcard.org/downloads/formatter_4/index.htmlinstead of Windows... copied all the data off of it, did a Quick Format with that Utility, and then copied everything back. It makes more sense that the Firmware doesn't like the SD Card data... now I can actually select an .ATR file.
Still not working so apparently I need to recheck my soldering (and now that I have printed a case I can do a better job of measuring everything), but getting closer...
- Thanks, Alan
-
2
-
-
Thanks for the quick reply... was hoping that might be a clue to something obvious and was hoping I wouldn't have to break it apart again. I'll do that and recheck everything and if I still can't get it to go then I'll post some pics.
Just following up on my issue where I could calibrate the touch screen, but then could not access any of the menu options. Fortunately when I ordered parts from Ali Express I ordered 2 of each. I flashed the other board and tried it with the same touch screen before doing any soldering... same result... so I tried my other touch screen and that works great. I apparently have a defective screen. Why it lets me calibrate and nothing else is a mystery I am not going to solve (???) and if that didn't happen with my first one I'd probably have had more confidence in everything.
Looking forward to trying it with my Atari computer later.
- Thanks, Alan
-
1
-
-
I can't seem to get adrive.atr to work on d0: It just says adrive.atr not found. Any idea's.
Yes, I'm guessing it's a typo, but isn't that supposed to be 'sdrive.atr'?
-
Please provide Pictures top and bottom of both board and screen close enough to fill the view, and also of both ends of wires including sio end and diode..
please also let us know version flashed...
Thanks for the quick reply... was hoping that might be a clue to something obvious and was hoping I wouldn't have to break it apart again. I'll do that and recheck everything and if I still can't get it to go then I'll post some pics.
-
Wondering if someone might have any suggestions as to what might be wrong with my SDrive-Max assembly...
I have it all assembled... upon powering on (and when powering on while touching the screen) I am able to successfully navigate through the calibration process followed by the screen telling me my calibration results followed by the main SDrive-Max screen, but on the main screen I cannot select anything... New, Cfg, drives... touch does nothing on any of them. D0 has a green light on it (?). I have also tried removing the SD card and I do get an error message where the READY prompt appears at the bottom of the screen.
This all leads me to believe my touch screen and Arduino are ok and from my tests my soldering connections seemed ok (although I'd expect to be able to select stuff on the touch screen regardless and would expect a failed SIO cable soldering job to just prevent it from working with the Atari computer).
Any ideas as to why my touch screen lets me calibrate, but I can't actually do anything once on the main screen? Thanks in advance.
-
-
I'd like one when available please.
-
To the detriment of other overdue projects, I'm experimenting with the basics of a new GUI system for the 8-bit. The mouse handler is just about finished (the reason this is taking so long is because the mouse is drawn in bitmapped graphics rather than using a PMG, and this necessitates extra work to ensure it always remains visible even when the underlying app is drawing to the screen), and everything else should keep me busy for the next six months or so.
There are two reasons this project interests me:
1) I find GUIs intrinsically fascinating, and I always wanted to write one.
2) At the risk of courting huge criticism from those who've already written good GUIs for the 8-bit, I think the world could stand another crack at it, since mostly they've either ended up as unsupported novelties, or elaborate ways of launching text-mode applications.
Diamond still seems the most ambitious attempt, and I'm inclined to make the new system partly or wholly compatible with the API described in the Diamond Developers' Kit. This doesn't mean, however, that the new system will look or work the same as Diamond. I think it's a mistake to try an implement a full-blown Windows type environment that the 8-bit can't really handle. GEOS on the Commodore 64, for example, didn't have moveable or sizeable windows, and if it had been running on a 1.7MHz 6502, it would have been quite useable. So we won't necessarily see overlapping windows, scroll bars, and the like with my system. It will be a framework for writing consistent applications which utilize a uniform mouse/menu/dialogue interface.
The system will also use proportional fonts, which is a good compromise between readability and maximising screen real-estate. Whether it will end up on a cartridge or not, I don't know. There's a huge amount of work to do and when I get a blank desktop with a working menu bar across the top of it, I'll know I'm getting somewhere.
The intention is to release it with a GUI version of The Last Word, plus a simple notepad type program, a handful of accessories, and a decent file manager. Being realistic at this stage in the game, life's too short to write a bunch of big applications on my own, so one of my most difficult tasks is going to be making this system attractive and accessible to the handful of programmers who might be inclined to write their own apps.
We can look at what happened to Diamond, which to my knowledge never had a single third-party application written for it. Perhaps my own effort will go the same way. I'd like from the offset, though, to get opinions from interested parties. What kind of GUI would you have liked to have seen twenty years ago on the Atari? What would you like such a system to do now? Do you think it's a waste of time?
I'd love to hear your views.
Thanks for the kind words about Diamond GOS... my view on it is...
a) I sure didn't have the money to support the project to the point that would have gotten 3rd party apps developed for it. I kept having whispers in my ear about Atari being interested, but they clearly weren't (as they were focused on the Atari ST). I never had any direct contact with Atari and don't know how much of what I heard was actually true vs hearsay, but in thinking about it now it seems a bit ridiculous to think Atari would have packaged an 8-bit computer with a GOS which would have somewhat competed with its Atari ST line of computers.
b) The install base wasn't there and when ICD pulled the plug on it (e.g. I got a phone call telling me I could order one last batch of cartridges and that was it and certainly didn't have the resources to make a huge order... a great lesson in binding your product to one supplier) I don't recall exactly how many had been sold, but I'd guess around 4 to 5 hundred at most... ultimately this is what killed it.
c) I didn't have the Comp Sci knowledge to do some of the stuff I would have done with it had I known what I know now. Better memory management is what comes to mind first.
- Alan
-
12
-
Like us on Facebook
Follow us on Twitter
AtariAge on Instagram
Watch us on YouTube
Chat on Discord
VIC-20 Repair?
in Commodore 8-bit Computers
Posted
Thanks hofster for guiding me to Ray's guide. I ended up removing the CD4066 and 74LS04 and adding sockets to make future maintenance easier. The 74LS04 tested as good so I kept that, but the CD4066 was defective. After doing that and verifying by swapping the bad one and a good one and seeing the difference I now had another problem... the characters were scrambled albeit in a mapped manner meaning every space was now a @, and * was J and so forth with some also being correct such as B was still B. Before all the characters mapped correctly... just the colors were off. I ended up getting a Penultimate+ cartridge for its Diagnostic tools (as I had planned to get one anyways once I had a working VIC 20) and then the machine starting booting to just a black screen... and then it magically started working. The Penultimate+ cartridge Diagnostic software verified the memory and ROMs as all fully functional. I'm a bit puzzled about all of this and it was consistent for many power cycles so how it just cleaned itself up is a ?. I can only wonder if when I was testing and I had the board just sitting in the plastic case vs on the paper/metal shield if it was in contact with something, but that seems farfetched. Anyhow, it's all back together now and fully functional. Yay!
On to the next project...