Home | Forums | What's new | Resources | |
Netlink ROM dumps |
hitomi2500 - Jul 11, 2021 |
vbt | Aug 2, 2021 | |||
what's the hardware used by the netlink ? i mean which cpu runs that ROM, it doesn't seem to be the saturn SH2s |
Waterfuell | Aug 2, 2021 | |||||
Got a microcontroller based on R6500, I asume is for emulate xband, because modem data pumps are diferent in xband and netlink, with diferent register configurations. |
Waterfuell | Aug 7, 2021 | |||||
To interface with xband modem ive used same addres set used by netlink and works the same, the registers in yabause wiki are not original registers from rc288dpi used in netlink (which got more registers an diferent maped),those register are from rcv144acfw from xband wich dont use external microcontroller, for that reason ive suposed microcontroler is for simulate the behaviour of an xband modem. |
antime | Aug 7, 2021 | ||||
The RCV144ACF chipset includes some kind of embedded microcontroller, guaranteed. The datasheet even talks about customizable firmware. There's no behaviour to emulate, serial port + AT commands has been the universal modem interface since the mid-80s. Different chipsets do have different custom commands, but the basic hardware interface and command set stays the same. One interesting question is if the Xband's smart card interface and on-board flash memory were accessed through the AT interface, or if they were directly mapped to the cartridge port. The readme for the Xband head-to-head library found on the 1996/11 DTS CD says
which suggests that they did indeed provide hardware-specific libraries. |
Waterfuell | Aug 8, 2021 | |||||||||||||
Surely you are right and AT interface is managed also by microcontroller, but hardware or electrical Interface with modem is accesing modem registers, if you take a look to two modem datasheets you will see netlink moden registers are not the same published in yabause wiki. So must be implemented in firmware to work the same way. At diference of XBand wich registers are exactly the same.
Rom and flash connects to some kind of memory mapper and also to modem ic and cartridge bus, ive supposed to update firmware if necesary, Ive dont look so deep, neither the smart card interface.
Ive used the DTS library with XBand modem, and works the same. |
antime | Aug 8, 2021 | |||||
Well yes, that's the AT command set, as I've been saying. The whole point of it is to act as a hardware abstraction layer, and there's nothing Saturn-specific about any of it. The RC288 is an internal implementation detail of that particular modem chipset, as is the internal structure of the RCV144 chipset. The external interface is an 16550 serial port, and the AT commands. The host never touches any modem registers directly, whether it's a Saturn or a PC. Where the RC288 data sheet block diagram says "host processor", that's the L39. |
Waterfuell | Aug 8, 2021 | |||||||||||||
Both RC288 and RCV144 can be interfaced with host as a serial device or parallel device, I cant say how netlink is interfaced, but in XBand, looking at IC routings I can say its interfaced as a parallel device with is host data and address lines conected, the addres lines are used to interface modem registers, hence to send AT comands and read responses you must read and write the register 0 or addres 0x25895001 seen from saturn memory map, and this must be done after set some of other registers to configure modem.
That can be true for netlink, but not for xband where the HOST PARALLEL BUS INTERFACE is the saturn cart bus.
Yes, can be called hardware abstraction layer, wich turns a newer device interface (Netlink) into an older device interface (XBand) to keep compatibility. EDIT: In RCV144 datasheet can see, the last P after dash means parallel host interface |
antime | Aug 8, 2021 | |||||
In the Netlink, the RC288's host port is connected to the L39's extension port, and the L39's host port (i.e. the 16550 serial port) is connected to the cartridge interface.
They're just modems, implementing the same interface as every other modem. There's no special backwards compatibility to implement. The only special feature about either is that apparently you have to separately enable the serial port via the SPMC. Edit: There's probably customizations in the bus interface, e.g. how interrupts are signalled compared to the ISA bus where these chips would usually be used, but that's completely transparent to the programmer. |
Waterfuell | Aug 8, 2021 | |||||||||
Cartridge interface dont have DTR DSR RTS CTS RI DCD i/o signals of a serial port, to acces this data you must read diferent modem registers.
If the interface is based in registers, and both data pumps dont share the same registers, you need the "abstraction layer" to make two devices compatibles. If you got DCD in two diferent registers mapped in diferent bits in diferent addres, you cant know where to search to see if you got carrier, the same for RI you cant know where to search to see if there is an incoming call, you can say, "you just need to wait for RING string in input bufer" but two data pumps neither share the same addres for input output registers, and netlink driver search in registers, and sets configuration writing in registers. XBand RCV144 registers listed in datasheet are the same listed in yabause wiki, and RC288 registers are not the same listed in yabause wiki, but got a microcontroller wich surely "emulates" those registers in saturn cartridge bus, so when you read 0x25895001 you will be reading register 0 in RCV144 and RC288, and when you write you will write in 0 for 144 and 10 for 288. And more complex for RI wich is not in same register and neither in same bit. EDIT: If you do (address&0x1C)>>2 to addres in yabause wiki you directly get RCV144 register addres, same cant be said for RC288 |
antime | Aug 26, 2021 | ||||||||
I don't understand what you're trying to say. The modem cartridges have a 16550-style USART that is mapped into the Saturn's cartridge area.
I don't understand why you keep going on about the data pump. It is a complete black box, as far as the application developer is concerned, and you have no access to it. Unless you're implementing the chipset yourself, you don't even know it exists. |