acadiel
-
Content Count
2,108 -
Joined
-
Last visited
-
Days Won
3
Posts posted by acadiel
-
-
29 minutes ago, brain said:OK, new Makefile pushed to repo.
Much better!
[email protected] MINGW64 /d/dev/HEXTIr-master $ ./make.exe CONFIG=config-arduino MKDIR obj-m328p-arduino/src/ CONF2H config-arduino CC src/diskio.c CC src/ff.c CC src/hexbus.c CC src/led.c CC src/main.c CC src/sdcard.c CC src/spi.c CC src/timer.c CC src/uart.c CPP config.h AS src/crc7asm.S LINK obj-m328p-arduino/HEXTIr.elf BIN obj-m328p-arduino/HEXTIr.bin HEX obj-m328p-arduino/HEXTIr.hex SIZE obj-m328p-arduino/HEXTIr.elf obj-m328p-arduino/HEXTIr.elf : section size addr .data 14 8388864 .text 12344 0 .bss 878 8388878 .stab 204 0 .stabstr 58 0 .comment 17 0 .note.gnu.avr.deviceinfo 64 0 Total 101941Will try flashing it next. Thanks!
-
1 minute ago, brain said:Already in the path..
[email protected] MINGW64 /d/dev/HEXTIr-master $ awk --version GNU Awk 5.0.0, API: 2.0 (GNU MPFR 4.0.2, GNU MP 6.2.0) Copyright (C) 1989, 1991-2019 Free Software Foundation. -
2 hours ago, brain said:make CONFIG=config-arduino progall
You'll probably need to find make and avr-gcc and friends in your environment somewhere and make sure they are in your path.
Here's where I am so far:
1) Download Microchip's AVR Toolchain for Windows and install (this may not be needed with the Arduino IDE - I'm not sure)
2) Download Make 4.3 for Windows and put in path
3) Download Awk for Windows and put in path
4) Download Git BASH for Windows
5) Download the latest Arduino IDE to get avrdude and avr-gcc and put C:\Program Files (x86)\Arduino\hardware\tools\avr\bin in the path.
On a side note, avrdude is already installed in the Arduino IDE. It's located here:
C:\Program Files (x86)\Arduino\hardware\tools\avr\bin>
I can program it via a command line like this (I haven't checked syntax yet):
avrdude -v -V -carduino -patmega328p -C"C:\Program Files (x86)\Arduino\hardware\tools\avr\etc\avrdude.conf" -PCOM8 -b115200 -D -Uflash:w:D:\dev\hexbus.bin
However, the make is giving me fits, and am not sure how to get past this.
[email protected] MINGW64 /d/dev/HEXTIr-master $ ./make.exe CONFIG=config-arduino CC src/diskio.c In file included from src/diskio.c:31:0: src/config.h:26:10: fatal error: autoconf.h: No such file or directory #include "autoconf.h" ^~~~~~~~~~~~ compilation terminated. make: *** [Makefile:365: obj-m328p-arduino/src/diskio.o] Error 1 [email protected] MINGW64 /d/dev/HEXTIr-master $ ./make.exe CONFIG=config-arduino progall make: *** No rule to make target 'progall'. Stop. -
1 minute ago, brain said:Pull and create a merge request for the install docs and I will merge. I'd rather not put the binary in there, since it'll be in the obj directory, and those are specific to board.
Jim
I think a binary would still have value, if we name it properly. A lot of folks are using an UNO - the binary should be cross compatible, as all of them use the 328P. We can specifically name the binary in that manner - like HEXTIr-Uno-328P-v1.0-bin. If someone else comes along and uses a Mega, or a Pro Mini (Microcenter sells those for like $4 - they use a 328P as well), we can just add those with the appropriate names and CPU.
-
33 minutes ago, brain said:make CONFIG=config-arduino progall
You'll probably need to find make and avr-gcc and friends in your environment somewhere and make sure they are in your path.
FYI, for others looking to do this, I found some steps for Windows, since WinAVR appears to be orphaned (and doesn't work well with 64 bit).
http://fab.cba.mit.edu/classes/863.16/doc/projects/ftsmin/windows_avr.html
Do you mind if I make a Windows-Install doc and upload it to your repo for a commit? How about me uploading the binary when done?
-
2 minutes ago, brain said:I didn't convert it to an Arduino project. You can use avrdude to program the raw AVR binary into the system.
Hi, Jim - could you please add build instructions? There's no entry point- no "runme.bat" - no .bin file, etc. I'm at a loss how to build it and would love an example if you could provide one. Thanks!
-
I wonder if they're available..
https://www.ued.net/ued/viewItemAction.do?itemCode=MSCSM-PHA4100
https://www.ued.net/ued/viewItemAction.do?itemCode=MSCSM-PHA4100A
I'd send them a note to confirm this is the 1983 model.
-
On 11/5/2019 at 2:29 PM, skullpin said:
This is the setup I have. I plan on putting a male connector for both Dockbus and Hexbus on the proto area, of course denoting pin #1.
-
I'm a bit at a loss on how to actually program the project at https://github.com/go4retro/HEXTIr to my Arduino in Windows. Typically, I see a sketch for an Arduino file with a .ino extension. I don't see that in the repo.
I use a Windows laptop for my Arduino programming if that helps... what do I need to do? Can anyone please explain how? Thanks!
I have a nice Uno (with a plastic bottom to protect it) and a shield like Jim posted. I do plan on putting a male Hexbus header and Dockbus header on the top of the back in the proto area - that part looks easy to do from the pictures in here and in the repo. I just got to get the thing programmed.
-
1 hour ago, Tursi said:
-
2
-
-
soapbox/
Hey guys, don’t dump on Tursi in his own thread, please. IMO, if you’re the only one having the issue, it’s your system. Try something else, or reload your system.
I never have had any issue with Classic99, and I use it from time to time to test things. Mike has put a lot of blood, sweat, and tears into his product, so it’s not good to bite the hand that feeds the community with an excellent TI emulator.
/soapbox
-
3
-
1
-
-
42 minutes ago, atrax27407 said:As I learned some years ago when Mark Wills and I were tracking down bugs in his excellent TURBOFORTH package, fixing a program to run in Classic99 is no guarantee that it will work in ANY TI real gear configuration. MAME (MESS) is a far more accurate representation of TI hardware but Classic99 is much easier to configure and use.
Mark used Classic99 for his development work and since he didn't have a working TI system at the time, used MAME (MESS) to test along with having me test TURBOFORTH on my real-gear system.
I've volunteered to be the guinea pig for Rich to do the testing on real iron.
If you think about it, Once the code is fixed, we can have a powerup routine in another GROM Bank (4, 5, 6, or 7) relocate the 4K code to a GRAM bank (G3). Then branch to the selection screen. So, G3 will then have a copy of the code, but since it's gram, the 2K it thinks it has (or actually, upper 4K since we use 8K GRAM not 6K) is writeable, just like the original module.
-
1
-
-
Rich Gilbertson and I had a great conversation last night around the BASIC Support module. According to Ksarul "The BASIC Support Module was a development cartridge with some additional routines in it that gave the developer a version ofBASIC that was more functional than TI BASIC, but nowhere near as capable as Extended BASIC."
There were two versions of it. Yep, two. A 4K and a larger one. Rich helped with that discovery after reading the code and looking at the 4K EPROM of the one we had. Physical copies exist of the 4K one - Ksarul has two of them. Bob Childress has another. (I plan on trying to bid on it when he puts it up so I can help preserve it and to get it working in the UberGROM.)
Rich and I are working on getting the 4K version working in the UberGROM, using the ability of the UberGROM to have an 8K GRAM bank.
I've attached pictures of the 4K version.
-
There is a 4K EPROM (mfgr varies) which has a little less than 2K of code with CALL @XXXX type calls. They all begin with @.
- BASICSUP is the ROM. Note that it's 6K in my image, but should really be 4K. Most everything after 2K is blank.
- There is also a 2K SRAM inside (mfgr varies.) These can be easily breadboarded and replicated.
- It's all discrete logic that emulates GROM/GRAM.
-
The cartridge comes up with three menu options when you boot it:
- 2 For GPL Prog at G(>7000)
- 3 For CPU Prog at G(>7000)
- 4 For CPU Prog at C(>6000)
- Note that there is no Cart space RAM (C>6000) in here, but it appears to support it.
- Some calls work, some don't. According to Rich, the GPL in the EPROM is broken. He is working on getting it fixed.
- It's important that either myself or someone else gets Bob Childress' copy in the eBay auction and dumps it so we can compare it to Ksarul's. I will be bidding on it and trying to buy it so I can analyze it and preserve it. I'm afraid of cart collectors trying to bid the price up on it. Bob doesn't have the capability to dump the 4K EPROM inside, unfortunately, before he sells it, and I doubt he would want to mail it to someone temporarily before he sells it - he sounds like he just wants to sell it and be done with it.
There is a larger version, too, and that one is the attached one below that Ksarul re-typed the source code for. This version, according to Rich, has XB related calls in it and was made to work in that environment. It's different from the 4K BSM in that there's a lot of Editor Assembler in it, and XB calls. Was this ever produced? We don't know. The first part of Jim's document about the CALLs and such is relevant to the 4K version of the BSM, but the source code is not. The source code is way more expanded, so TI must have had a larger version of the BSM planned at one point.
Anyway, I'm putting this thread here so that everything is in one place. Thanks to Rich for helping make the discovery about the two versions, Jim for scanning in the docs and providing the 4K ROM to analyze, and Bob for putting up internal pictures so we could compare the two.
Manual:
-
9
-
2
-
There is a 4K EPROM (mfgr varies) which has a little less than 2K of code with CALL @XXXX type calls. They all begin with @.
-
We need to better identify the following on this list, and I can help a bit. These aren't all games, but these are the ones I've been converting to UberGROM. It's important to realize that a lot of these started out as #6 and got converted to #4 and #5, so they were never natively released as #1/#2/#3.
1) Items that actually have a native GROM image
2) Items that actually had native GROM+ROM images
3) Items that were a native ROM cart image
4) PROGRAM image items that were converted to GROM images (run from 32K)
5) PROGRAM image items that were converted to ROM images (run from 32K)
6) PROGRAM image (32K)
* = Exists as UberGROM image as of 4/1/20
*Angler Dangler - 4/5/6
Ant colony - 3
Astro Fighter - 4/6
BASIC Support Module - 1 (* some had 2K RAM)
Cannonball Blitz - 4/6
Cave Creatures - 4/6*Card Sharp - 1
*Crossfire - 2
*ET (Frogger type game) - 2
*ET and His Adventures on Land - 1
*ET and His Adventures at Sea - 2
*Fantasy - 2
*Germ Patrol - 2
*Lasso - 4/5/6
*Lobster Bay - 4/5/6
*MB Gamevision Demo Cart - 1
Mission X - 4/6
*Mouskattack - 2
Paddle Ball (Breakout) - 4/5/6
*Peter Pan's Space Odyssey - 2
*Pinnochio's Great Escape - 2
*Plant Genetics - 2
River Rescue - 4/6
Submarine Commander 4/6Robotron - 3
Shanghai - 3
*Simon Says - 1
*SMU Engineering - 1
*Starship Pegasus - 2
Super Storm - 3
*Test Trainer - 2
*TI Calc - 2
*Tutankham - 2
*Verb Viper - 1
*Von Drake's Molecular Mission - 2
*Wing War - 2
It's important for those labeled 4/5/6 that I get the original PROGRAM images for these so that I can convert them to "run from ROM". Many of these were converted to GROM, which need an UberGROM to emulate, and the ROM carts are less expensive to build, so I want to give people that option too. It'd be nice to actually make PROGRAM, ROM, and UberGROM images available for all of the ones that people released as "copy to GROM" (examples: Astro Fighter, Mission X, Cannonball Blitz, Cave Creatures, River Rescue, Submarine Commander, Angler Dangler, Lobster bay, and Lasso.)
Please attach these to any replies so I can test them. Need clarification on ones I don't have, which are:
Astroblitz
Jumpman Junior (probably 3 - Junkman Jr exists anyway, so this probably doesn't matter)
Star Wars: ESB
-
4
-
1
-
-
TI Workshop uses a PAL16R4A-2CN. 64K. 27512 EPROM. None of my programmers can read/write these. There likely needs to be an older model for this kind.
PAL16R4A-2CN Pinout:
1 - N/C
2 - DBIN
3 - A12
4 - A11
5 - A10
6 - A3
7 - A8
8 - A1
9 - A0
10 - GND
11 - VCC
12 - N/C
13 - N/C
14 - N/C
15 - A13
16 - A14
17 - A15
18 - CRUCLK
19 - A4
20 - GND
No idea why they hooked up all these address lines when they only really needed to control four of them. Plus, they left out A2, A5, A6, A7, and A9. Thoughts?
-
3
-
-
4 hours ago, Ksarul said:ISTR that the PAL in it does support switching up to 64K, which makes sense, as TI workshop actively uses a 64K space, and it is based off of the SS II board.
Yep. Supposedly the fuses are burnt, so I can't read the ones in mine. But we pretty much know the logic and writes (which enable certain address lines in the ROM/RAM), so the community can definitely figure out the GAL/PAL.
-
4 minutes ago, OLD CS1 said:SuperSpace II is 32k CRU-switched banking. The manual includes information on how to accomplish the bank-switching.
DataBiotics used the SS scheme on a few carts:
Red Baron (32K)
Desktop Publisher (32K)
TI Workshop (64K)
Stargazer I/II/III (32K)
So yeah, it’s definitely extensible to 64K. They probably just didn’t do it.-
1
-
-
I'm wondering how hard it would be in programmable logic for us to to emulate the CRU Bank switching nowadays. It's just a 64K SRAM chip with a PAL/GAL controlling bank switching via CRU.
(I think this is how it works - someone please correct me if I'm wrong on any of these points.)
We can probably take the 128K board or Ksarul's Supercart board and adapt the pinout of the 378 for the PAL/GAL, plus make space for an EA GROM. We'd have to get community involvement to develop the PAL/GAL formulas. All that happens (just off the top of my head) is that bit patterns are written to CRU >0800 (0001, 0010, 0100, and 0110 for the 32K one, more for the 64K one). These then enable/disable address lines on the 64K SRAM so you get different 8K space:
0000 0000 0000 0000 - 0001 1111 1111 1111 - 0-8191 >0000-1FFF
0010 0000 0000 0000 - 0011 1111 1111 1111 - 8192-16383 >2000-3FFF
0100 0000 0000 0000 - 0101 1111 1111 1111 - 16384-24575 >4000-5FFF
0110 0000 0000 0000 - 0111 1111 1111 1111 - 24576-32767 >6000-7FFF
You could also continue the pattern for a 64K SRAM:
1000 0000 0000 0000 - 1001 1111 1111 1111 - 32767-40959 >8000-9FFF
1010 0000 0000 0000 - 1011 1111 1111 1111 - 40960-49151 >A000-BFFF
1100 0000 0000 0000 - 1101 1111 1111 1111 - 49152-57343 ->C000-DFFF
1110 0000 0000 0000 - 1111 1111 1111 1111 - 57344-65535 >E000->FFFF
I don't think they designed this to be more extensible than 64K because of them using the first set of four bits to present to the CRU address. Were there other ways around this?
-
3 hours ago, mizapf said:This also means that the MAME dumps cannot be used in HSGPL or UberGROM. You'd have to "unfold" the ROMs again to make 4*8K.
Correct. There's no "partial bank switching" - we bank the whole 8K segment. So, if you want to repeat the first 4K, simply just repeat the ROM with the first 4K in each of the four "banks".
-
18 hours ago, mizapf said:But only the GROM and rom-2 have valid CRCs. Did you "fix" the other ROMs?
All I did to properly "format" these for programing the Ubergrom is:
1) Separate ROM images into 8192 byte images
2) Separate GROM into 6144 byte images
3) If the image was less than 8192 or 6144, I padded to 8192 or 6144
4) I then concatenate the ROM images (.C times 64, .C+.D times 32, or .C+.D+.E+.F times 16) to fill the whole 512K ROM
I then:
5) Program the 512K ROM on my EPROM Programmer
6) Program the 1284P on my EPROM Programmer with the vanilla GROMSIM image
7) Put the GROM 6K files on my USB Flash drive .HFE image via TIImage Tool.
8] Move the USB Flash Drive to my /4A GoTek
9) Program the GROM 6K files (G3/G4/G5/G6/G7 from my /4A to the 1284 with GROMCfg
10) Reboot, and the cart works
Otherwise, the images are the same exact ones that Flottman gave me, this is attached.
-
1
-
-
14 hours ago, Flottmann1 said:for Classic99
TI-PLANNER
and TI-CALC
TI Planner (1987)(DaTaBioTics)[AKA Console Calc].C 8 kB · 2 downloads TICALC_3.BIN 32 kB · 2 downloads TICALC_G.BIN 6 kB · 2 downloads
Completely different programs.
TI Calc is much larger. Planner is one ROM. TI Calc is 32K ROM + 8K GROM.
-
Here you go. I attached the four proper ROMs and the GROM. I also attached the UberGROM ROM (where I reversed the four banks and then concatenated them over and over into a 512K rom).
If the four ROMs aren't in the correct order for the bank sswitching scheme, the cart won't work.
-
4
-
-
2 minutes ago, Flottmann1 said:I'll take a look to see if it's a true GROM. Thanks!
-
Flottman's version worked - after I reversed the four 8K banks, and then copied that 32K block sixteen times to fill the 512K ROM chip.
I now have a working cartridge. Thank you!!!
-
2
-
Like us on Facebook
Follow us on Twitter
AtariAge on Instagram
Watch us on YouTube
Chat on Discord
The Compact Computer 40 (CC40)
in TI-99/4A Development
Posted
[email protected] MINGW64 /d/dev $ avrdude -v -V -carduino -patmega328p -C"C:\Program Files (x86)\Arduino\hardware\tools\avr\etc\avrdude.conf" -PCOM4 -b115200 -D -Uflash:w:HEXTIr.bin avrdude.exe: Version 6.3-20190619 Copyright (c) 2000-2005 Brian Dean, http://www.bdmicro.com/ Copyright (c) 2007-2014 Joerg Wunsch System wide configuration file is "C:\Program Files (x86)\Arduino\hardware\tools\avr\etc\avrdude.conf" Using Port : COM4 Using Programmer : arduino Overriding Baud Rate : 115200 AVR Part : ATmega328P Chip Erase delay : 9000 us PAGEL : PD7 BS2 : PC2 RESET disposition : dedicated RETRY pulse : SCK serial program mode : yes parallel program mode : yes Timeout : 200 StabDelay : 100 CmdexeDelay : 25 SyncLoops : 32 ByteDelay : 0 PollIndex : 3 PollValue : 0x53 Memory Detail : Block Poll Page Polled Memory Type Mode Delay Size Indx Paged Size Size #Pages MinW MaxW ReadBack ----------- ---- ----- ----- ---- ------ ------ ---- ------ ----- ----- --------- eeprom 65 20 4 0 no 1024 4 0 3600 3600 0xff 0xff flash 65 6 128 0 yes 32768 128 256 4500 4500 0xff 0xff lfuse 0 0 0 0 no 1 0 0 4500 4500 0x00 0x00 hfuse 0 0 0 0 no 1 0 0 4500 4500 0x00 0x00 efuse 0 0 0 0 no 1 0 0 4500 4500 0x00 0x00 lock 0 0 0 0 no 1 0 0 4500 4500 0x00 0x00 calibration 0 0 0 0 no 1 0 0 0 0 0x00 0x00 signature 0 0 0 0 no 3 0 0 0 0 0x00 0x00 Programmer Type : Arduino Description : Arduino Hardware Version: 3 Firmware Version: 4.4 Vtarget : 0.3 V Varef : 0.3 V Oscillator : 28.800 kHz SCK period : 3.3 us avrdude.exe: AVR device initialized and ready to accept instructions Reading | ################################################## | 100% 0.00s avrdude.exe: Device signature = 0x1e950f (probably m328p) avrdude.exe: reading input file "HEXTIr.bin" avrdude.exe: input file HEXTIr.bin auto detected as raw binary avrdude.exe: writing flash (12358 bytes): Writing | ################################################## | 100% 1.98s avrdude.exe: 12358 bytes of flash written avrdude.exe done. Thank you.Looks like it worked! Going to go try it.