I was working on the imagewriter II but got stuck trying to figure out the gate array.
I happened to notice a skeleton by AJR for the NLQ401 and thought I'd give it a stab.
I was able to get the cr steppers working, then the lf steppers, and got the buttons working but it just wouldn't go into the self test. After doing some machinations with the debugger, the self test is doing something.
I've got the print head a little backwards but finally, it's doing something recognizable!
ok, got the printhead pins in the right order.
was able to coax a few characters to be printed but there's a flipflop on the schematic that I haven't implemented yet.
Nice work. Could you have a look at the MPS-1230? This code has sat there rotting for 9 years. (https://github.com/mamedev/mame/blob/master/src/mame/commodore/mps1230.cpp) This is a combo NLQ parallel / Commodore IEC printer so it can be used on many different computers. I own a working MPS-1230 if any more info is needed. There's a Guru-Reame in the src.
I've been studying the MPS-1230 a little bit and it looks possible.
The schematic's a little confusing but it looks like it drives the carriage motor left and right with PA0 and PA1 and uses an encoder to detect the movement which sets off interrupts, as opposed to using a stepper motor. I think PA4-PA7 drive the LF motor.
There's accesses in E000-E009 range which must go to the gate array, but that's completely undocumented.
The PEEK rom version has a checksum that will pass if we change the memory map to go up to bfff. The upper areas of the rom is filled with FF.
Thought that the Amstrad DMP1 would be simple, but it has been quite difficult. I've been trying to figure out why my code didn't work, finally realizing that the rotation detector disc spins whenever the motor runs. After realizing that, I read a blurb in the VIC-1515 manual that said "fixed to motor shaft".
It uses a Seikosha uni-hammer design (one single hammer that does the work of 7 pins). It's quite a clever cost reduction, as well as using a spring to return the carriage to the left.
It's very similar to a lot of printers, like the Atari 1029, the MPS-801, and the VIC-1515/1525 (Tandy DMP-100, Gorilla Banana)
I finally got it to do something kind of recognizable.
Maybe it's a bit late since you figured it out already, but here you have some comprehensive info on Amstrad printers, including manuals, service manuals, rom dumps, etc: https://www.cpcwiki.eu/index.php/Peripherals#Printers
Thanks, Rob, the cpc site is my go-to resource for these printers, it's really well done and neatly organized. I probably wouldn't have even tried the nlq401 without the collected technical info.
Could you have a look at the Commodore VIC-1520 Plotter.... should be low-hanging fruit. There's a driver but like a lot of non-essential peripherals it does nothing and hasn't even been implimented correctly as only IEC4 is available. I ran the C64 emulation and added the VIC-1520 (IEC4) and it didn't do anything and just gave me syntax errors just trying to output a simple program listing in direct mode typed directly from the manual. I added a MPS-1200 (IEC4), reset the C64 and all it did was crash to the desktop :-/
The user manual for the 1520 says it's mapped to IEC6 by default and the emulation doesn't expose IEC6 in the slot devices so it will never work regardless. The manual doesn't mention anything about changing the device number so 6 is required for the plotter with no other options. The most basic printing in direct mode is... OPEN 3,6 CMD 3 PRINT #3,"VIC-1520 TEST" CLOSE #3
At PRINT #3 there is an expected 'DEVICE NOT PRESENT' error.
With the 1520 there's no complex/unknown gate array or dot matrix stuff, basically just plot pixels where ever the pen is positioned when it's down and dump it to a png or whatever the normal output method is in MAME for printing devices. Electronically it's very simple using a 6501 with internal ROM and there are 2 ROM versions dumped. There's a rom dissassembly here.... https://www.zimmers.net/anonftp/pub/cbm/firmware/printers/1520/index.html
There are so few (or no) printers working in MAME so it would be nice to have at least one Commodore printing device working and the plotter is likely to be the simplest and easiest one that can be made to work
I hooked up the steppers on the 1520 and finally got something that looks sane. It draws 4 boxes on power up. More stuff to figure out, but looks promising.
The pen up and down signals are reversed on the schematic, when I switched them it looked much better.
Excellent! Yeah that's the self test at power-on, always does that. The boxes are supposed to be the 4 colors of the built-in pens, in order, blue, green, red, black. Apparently this same mechanism was also used in the Sharp MZ-731 which has a built-in 4-pen plotter but that computer doesn't seem to be in MAME (and roms don't seem to be available). It would probably fit into sharp/mz700.cpp if roms can be found. Edit: Found out the plotter was sold separately as Sharp MZ-1P01 (https://original.sharpmz.org/mz-700/useplot.htm and https://original.sharpmz.org/mz-700/plotterctrl.htm) and plugs into the MZ-700 motherboard to make it into a MZ-731. That plotter rom is available on that site in the MZ-700 section but it uses a 8050 microcontroller so it appears only the plotter mechanism is the same not the controller board, although the schematic looks very similar to the Commodore one (https://original.sharpmz.org/mz-700/mz-1p01.htm). It could be added to the MZ-700 driver if it can be emulated since the motherboard can accept it as a standard peripheral add-on then basically it 'just works' hehe! There's more technical info about the plotter in the service manual (https://original.sharpmz.org/mz-700/download/sm700.pdf) which may relate also to the Commodore version.
Last edited by Guru; 07/28/2403:22 PM. Reason: added more info
I decided to read up again on the commodore iec bus and try to grok what was happening. I looked at understanding the IEC bus awhile back and couldn't make head nor tails of it but it actually made some sense to me.
The 6500/1 looked like it wasn't reading from the port A properly.
After modifying a single line in 6500_1.cpp:
Code
u8 m6500_1_device::read_port(offs_t offset)
{
if (!machine().side_effects_disabled() && !m_port_in_cb[offset].isunset())
{
u8 const prev(m_port_in[offset]);
m_port_in[offset] = m_port_in_cb[offset]();
if (!offset)
{
u8 const diff((prev ^ m_port_in[0]) & m_port_buf[0]);
if (BIT(diff, 0) && BIT(m_port_in[0], 0))
m_cr |= CR_A0ED;
if (BIT(diff, 1) && !BIT(m_port_in[0], 1))
m_cr |= CR_A1ED;
update_irq();
}
}
// return m_port_in[offset] & m_port_buf[offset];
return m_port_in[offset]; // not seeing all of the data, try this
}
and boom it starts working!
Reading the code, it adds #$24 to the 3 bit IEC number from the jumpers, so it ends up getting device 11 since I'm returning 7 from the jumpers. I've got the steppers going in the wrong direction, but it's doing something!
OPEN 4,11,0 PRINT #4,"HELLO" PRINT #4,"IS THAT CYRILLIC?"
Excellent!! That demo program is a bit crap really, it's doing it as a bitmap. In reality the pen can draw proper arcs and lines very quickly. That whole demo shouldn't take more than 60 seconds if it was done using proper geometric shapes instead of little jagged lines. Would be interesting to see it in action on a C128 using BASIC 7 or a Plus/4 with BASIC 3.5 as the newer basics have many graphic drawing commands. But yeah great to see it working and I'm looking forward to trying it out in MAME.
I read somewhere there's a similar plotter with the same mech for one of the early Atari computers too. The Atari 1020 service manual with schematic is here.... https://www.atarimania.com/documents/atari_1020_Field_Service_manual.pdf Looks like it has a 6805 and a 68705P3. Of course no dump because most people (especially the Atari collector crowd) believe their gear will last forever so there is no attempt to archive the ROMs etc.
Found a couple of schematics of the Atari 1029 dot matrix printer along with a rom and was able to get it to do the self test. It's very similar to the Amstrad DMP1 (seikosha uni-hammer) but also has significant differences (no 8243 i/o expander and no centronics interface). Hopefully I can get the SIO to work.
There was an issue with the a800 antic not liking multiple screens,
Ignoring MAME exception: No screen specified for device ':antic', but multiple screens found Fatal error: No screen specified for device ':antic', but multiple screens found
Adding the line m_antic->set_screen seemed to fix it.
Doing research on other printers, I was interested in the Commodore MCS-801 (not to be confused with the MPS-801). This was a color printer that used a "4-hammer method."
Interestingly, it could do 4 colors in a single pass of the printhead. How is that possible? I came across a patent that's quite interesting.
So it's just like the uni-hammer printer, only this time it has 4 hammers that will each print a specific color in a specific column as the printhead sweeps from left to right.
If you like simultaneous color have a look at the MCS-810/820 These are Commodore re-branded Okidata Okimate 20 which is a thermal printer. It can use thermal paper (printing in black only) or it can use a ribbon cartridge that has a 1-time-use plastic tape ribbon with some sort of wax 'ink' that gets heated and fused to plain paper. I had an Okimate 20 around 1986 but the head went bad after a few years so I tossed it.
Looks like a 16kB EPROM, 8kB x8-bit RAM and a 8051 but maybe the 8051 is in external ROM mode and can be coaxed to do something just with the EPROM code.
It was hellishly slow so if you get it working insert some time delays and a bang noise every time the printer head moved forwards onto the paper then backwards off the paper to make it more real-life ;-P
Thought I'd try the MPS-801 and was able to get it to go into the self test. It wasn't working at all and that baffled me for a couple of days, then I had the idea to negate the dot sensor input and it started working!
There's also a Sams computerfacts on the okimate 20.
I found a manual with schematics for the PC-2 (which I assume is the same as the sharp PC-1500 and the CE-150) so I'm going to take a swing at it.
edit: Added the rom and the io chip into the memory map and it seems to be moving the x and y steppers but it won't settle down. More investigation needed.
also noticed that the lh5801 disassembler gives odd numbers for the relative branches,
case RelP: temp=opcodes.r8(pos++); util::stream_format(stream, "%s %04x", entry->ins_name(),pc+pos+temp);break; case RelM: temp=opcodes.r8(pos++); util::stream_format(stream, "%s %04x", entry->ins_name(),pc+pos-temp);break;
changing that to just pos+temp and pos-temp instead of pc+pos+temp and pc+pos-temp makes it more sane.
Ok, got the VIC-1515 doing the self test. This printer uses a motor shaft rotation detection disc like the other seikosha unihammers, however, it has a different structure.
So I looked at my kludgey code to generate the detection disc and wanted something more elegant.
After spinning on it for awhile, why not use cpp macros.
Instead of a bunch of complicated code, this is much easier to modify for a different wheel pattern.
Code
#define REP(x,y) for(int loop##x=0;loop##x<y;loop##x++)
#define ADD(v) m_rotation_detector[rotsize]=v;m_xoffset[rotsize]=col;m_yoffset[rotsize++]=pix;
#define NEXTCOL col++; pix=0;
#define NEXTPIX pix++;
#define A REP(x,7) { ADD(0) ADD(1) NEXTPIX }
#define B REP(x,3) { ADD(0) ADD(1) NEXTPIX } NEXTCOL
#define C REP(x,7) { ADD(1) }
u8 col = 0;
u8 pix = 0;
u8 rotsize=0;
A B A B A C
The VIC 1515 also uses a different paper feed mechanism. There's a solenoid that moves a sawtooth along. It fires 3 discrete times for a text line, 2 times for a graphic line.
I was having problems with stray dots everywhere, finally tracked it to using > instead of >= when checking against the size of array for the rotation detector.
Been really struggling with the MPS-802/1526, finally got it doing something!
Was so close to getting it working for a couple of days but it just wouldn't go.
Then I finally realized that I copied and pasted some code and was referencing the pf stepper instead of the cr stepper in checking for horizontal motion.
and with a little fixing, setting the horizontal dpi to 80 and getting right side up:
The 8023P printer (aka MPP-1361) is similar to the MPS-802, but I can't quite get it working and doing the self test. It has a cylindrical cam with a detector that signals "ready to print".
There's videos on youtube that show the spiral cylinder and the detector (like a semi circular piece).
There is original source code to the printer's rom (for version 1), which is makes it a little easier to figure out.
It also has the same test for the 6522 and 6532 timers as the MPS-802.
tmtest ;test timers inc f ;advance error count lda #$ec sta crclk lda #$ee sta pfclk lda #0 sta crclk+1 sta pfclk+1 lda #$f5 sta ndclkd+8 lda #$fb sta dmclkd+8 tt10 lda crclk bne tt10 tt20
(shows off the cylinder and detector at 7:24 mark)
One odd thing is that the printer has 2 x 2114 memory chips which should provide 1K of ram. However, as far as I can tell, it only seems to use the lower 512 bytes of the ram, 3000 up to 31ff.
The source actually has the test for the upper 512 bytes, but it's commented out. I guess they could use ram chips that had a bad upper 512 bytes.
More likely 512b RAMs were difficult to source so they just used what they had in stock. The MPP-1361 manual has a date of 1983 which fits with the time C64's were in production. 2114 is used in C64 as the color RAM. Likely they just grounded the highest address pin A9 to halve the capacity. I just discovered Seibu did the same thing on the SPI boards with the 32kx8-bit SRAMs connected to the RISE11 chip. The upper 4 address lines are tied high or low making these RAMs effectively 2kB and with 2 chips connected it means the RISE11 has 4kB connected to it, not 64kB.
So according to the schematic, there's a hall effect sensor ULN3006-T which will shut off printing if it's activated.
The only thing I could find out about it is this from a sprague databook:
"Intended for use in position sensing and contactless switching applications, the UGN-3201K switch utilizes the Hall Effect for detecting a magnetic field. It is supplied in a four-pin single in-line plastic package. The switch was originally introduced as ULN-3006."
The MPP-1361 schematic doesn't have this sensor at all.
So now it'll go into the self test and start printing.
But sometimes after the second line the carriage just keeps going to the left.
You can see how I've reset it a few times.
edit:
I think it has something to do with the bidirectional printing moving left and hitting the home sensor while it's still printing a character.
If you look at the printouts that fail, it clips the leftmost dots on the return sweep.
The print head must slip a little while it's changing direction, which we don't model.
After adding a fudge factor on the home sensor when we're moving leftward, it seems to work consistently every time (so far).
(the red line is the RTP sensor, and the blue line is the home sensor)
I came across this post on the Tandy DMP-100 being very similar to the the Tandy Line Printer VII, the major difference being that the DMP-100 can do graphics.
I managed to find an english service manual/technical manual for the NLQ401 and it had an interesting bit: There were two versions of the main board, one with a upd7810 and another that used a upd7809.
Sadly, I don't think you'll ever be able to properly emulate the Tandy DMP-200 dot-matrix printer. That thing had a distinctive, LOUD sound in operation-- we're talking 80 decibels-- and that's hard to capture in an emulation.
It's fascinating to research some of these old dot matrix printers. I was studying the Tandy Line Printer I service manual and it doesn't use a microprocessor. It uses ram and rom chips along with binary counters and logic to detect the codes CR and LF. It gets 7 bit data from a parallel port.
The rom chip output data is the bit pattern to drive the 7 printhead pins.
The Line Printer I has a motor driven belt and when the printer wants to move the carriage forward it hits a solenoid that catches the belt and moves it forward. There's another solenoid that moves the carriage in reverse by catching the belt moving in the opposite direction.
================
I'm trying to get the MPS803 to receive data from the c64 but it doesn't quite see the data.
Using the debugger and watchpoints we can see the data that the c64 is putting on the bus:
>bp ed62,1,{printf "DATA TO SEND %x",b@95;g} Breakpoint 1 set >g DATA TO SEND 24 DATA TO SEND 3f
so the c64 is sending 24 to tell the printer to listen, then after not getting a response, sends 3F to unlisten.
I found a schematic for the Tandy CGP-220 which is like the Canon PJ-1080A. This printer prints a single line at a time so it's a little slow, but it can print 4 colors (black + CMY) on a single line. Note that this is a single "pixel" line so the head has to travel back and forth a lot.
I don't have a rom for the CGP-220 but I do have one for the Canon PJ-1080A and the 6809 code looks reasonably sane. However, the schematic for the CGP-220 is different from the PJ-1080A.
It uses a PTM6840 and a PIA6821. So far I haven't been able to make it do anything but it's interesting to study.
I took a look at the roms for the Amstrad DMP-3160 and they look remarkably similar to the Amstrad DMP-3000.
Doing s disassembly and plugging it into meld, aside from the first 4kb, there are only a few differences:
(the blue bars on the sides highlight where the files are different)
The DMP-3000 dump doesn't include the first 4k as the upd7811 has the 4k rom on chip.
I was able to get it to go into the self test, but for some reason it's only printing the space character 0x20 over and over.
Using the debugger to catch the process where it puts characters into the buffer, I can manually add some characters, in this case the letters ABC.
The lines of dots are the 9th pin, which I haven't hooked up yet,
edit:
some more fiddling and discovered that there are two self test modes, one with holding down lf and another with holding down ff on power-on. Holding down lf will do a self test with printing, and ff will do a self test with no printing, just carriage movement.
I got interested in the Alphacom VP42 printer. It uses an Olivetti PU-1840 mechanism that prints 40 columns using 20 thermal elements. It uses a 6500/1 cpu along with a couple of DS3654 printer solenoid drivers that are basically 10 bit shift registers. 2 x 10 bit shift registers is enough to drive all 20 thermal elements.
There's a great article in the Personal Computer World 1981-03 that gives a lot of information on the PU-1840.
It took me quite a while to figure out how the code works to send the data to the shift registers.
Now we'll see if I can make it do something...
Code
mem=manager.machine.memory.regions[":iec4:vp42:mcu"]
function stars(x) local a = "" for j=7,0,-1 do if ((2^j) & x)==0 then a=a.." " else a=a.."*" end end return a end
for k = 0,159 do for i=0xac1,0xddc-1,159 do a=mem:read_u8(i-0x800+k) print(string.format("%x",i).." "..string.format("%x",k).." "..string.format("%x",a),stars(a)) end print() end
ac1 80 32 ** *
b60 80 49 * * *
bff 80 79 **** *
c9e 80 41 * *
d3d 80 3e *****
ac1 81 7c *****
b60 81 12 * *
bff 81 11 * *
c9e 81 12 * *
d3d 81 7c *****
ac1 82 7f *******
b60 82 49 * * *
bff 82 49 * * *
c9e 82 49 * * *
d3d 82 36 ** **
ac1 83 3e *****
b60 83 41 * *
bff 83 41 * *
c9e 83 41 * *
d3d 83 22 * *
ac1 84 7f *******
b60 84 41 * *
bff 84 41 * *
c9e 84 22 * *
d3d 84 1c ***
ac1 85 7f *******
b60 85 49 * * *
bff 85 49 * * *
c9e 85 41 * *
d3d 85 41 * *
...
Took a look at the Amstrad PCW 8256 and realized that the shift register wasn't working quite right, it should shift only on positive clock transitions.
so the stepper motor steps at full steps, and if we just use the current position, it looks terrible.
If we use a simple algorithm of using the last stepper position as our "starting position" and add an amount based on our current speed and the elapsed time interval, it looks 100% better.
edit: tried the same routine on the Amstrad dmp3000 self test:
The documentation for the stepper motor controller blocks in Toshiba MCUs refer to a (programmable) difference between full-step excitation and half-step excitation. That sounds a little like what's going on here.
I instrumented it with a bunch of printfs and it looks like it's doing full steps and firing the pins in between the steps, so you get sub-halfstep resolution.
The 0x1ff for the pins is like a "nop" where it fires the pins, but no pins will energize.
cr STEPPER = 4 4 Update pos=525.000000 Speed = 466.645880 average with last = 471.960753 time=310.099806 FIRE @ 310.100580 sincelast=0.000870 pins=17f FIRE @ 310.101454 sincelast=0.000874 pins=1ff FIRE @ 310.102325 sincelast=0.000871 pins=17f FIRE @ 310.103198 sincelast=0.000873 pins=1ff STROBE 8c cr STEPPER = 8 1 Update pos=527.000000 Speed = 488.889333 average with last = 477.767607 time=310.103897 FIRE @ 310.104072 sincelast=0.000874 pins=17f FIRE @ 310.104944 sincelast=0.000871 pins=1ff FIRE @ 310.105816 sincelast=0.000873 pins=17f FIRE @ 310.106690 sincelast=0.000874 pins=1ff FIRE @ 310.107562 sincelast=0.000871 pins=17f STROBE 1c cr STEPPER = 1 8 Update pos=529.000000 Speed = 477.275626 average with last = 483.082480 time=310.108088 FIRE @ 310.108434 sincelast=0.000873 pins=1ff FIRE @ 310.109309 sincelast=0.000874 pins=160 FIRE @ 310.110180 sincelast=0.000871 pins=1df FIRE @ 310.111053 sincelast=0.000873 pins=17f FIRE @ 310.111927 sincelast=0.000874 pins=1ff STROBE 2c cr STEPPER = 2 2 Update pos=531.000000 Speed = 477.586454 average with last = 477.431040 time=310.112276 FIRE @ 310.112799 sincelast=0.000873 pins=17f FIRE @ 310.113671 sincelast=0.000871 pins=1ff FIRE @ 310.114544 sincelast=0.000873 pins=17f FIRE @ 310.115418 sincelast=0.000874 pins=1df STROBE 4c FIRE @ 310.116289 sincelast=0.000871 pins=17f cr STEPPER = 4 4 Update pos=533.000000 Speed = 477.275626 average with last = 477.431040 time=310.116466 FIRE @ 310.117162 sincelast=0.000873 pins=1ff FIRE @ 310.118036 sincelast=0.000874 pins=17f FIRE @ 310.118907 sincelast=0.000871 pins=1ff FIRE @ 310.119780 sincelast=0.000873 pins=17f
I was using the stepper from machine/steppers.cpp but the "standard drive table" isn't used by many steppers.
If you break it down, steppers use 4 bits for the phase, and if you swap the bits around you can make one "drive table" equivalent to another.
I'd rather be able to call a routine to set the "drive table" by using a list of bit positions.
If you had a list of bit positions, you can choose which bit is the start, then the next, all the way to the last.
Code
void stepper_device::advance_phase()
{
//Standard drive table is 2,6,4,5,1,9,8,a
//NOTE: This runs through the stator patterns in such a way as to drive the reel forward (downwards from the player's view, clockwise on our rose)
//The Heber 'Pluto' controller runs this in reverse, this needs checking on real hardware
switch (m_pattern)
{ //Black Blue Red Yellow
case 0x02:// 0 0 1 0
m_phase = 7;
break;
case 0x06:// 0 1 1 0
m_phase = 6;
break;
case 0x04:// 0 1 0 0
m_phase = 5;
break;
case 0x05:// 0 1 0 1
m_phase = 4;
break;
case 0x01:// 0 0 0 1
m_phase = 3;
break;
case 0x09:// 1 0 0 1
m_phase = 2;
break;
case 0x08:// 1 0 0 0
m_phase = 1;
break;
case 0x0A:// 1 0 1 0
m_phase = 0;
break;
// Black Blue Red Yellow
case 0x03:// 0 0 1 1
{
if ((m_old_phase ==6)||(m_old_phase == 0)) // if the previous pattern had the drum in the northern quadrant, it will point north now
{
m_phase = 7;
}
else //otherwise it will line up due south
{
m_phase = 3;
}
}
break;
case 0x0C:// 1 1 0 0
{
if ((m_old_phase ==6)||(m_old_phase == 4)) // if the previous pattern had the drum in the eastern quadrant, it will point east now
{
m_phase = 5;
}
else //otherwise it will line up due west
{
m_phase = 1;
}
}
break;
}
}
Code
u8 m_stepper_pattern[4] = {1, 2, 0, 3}; // "standard table" goes from bit 1 to bit 2 to bit 0 to bit 3.
bool m_stepper_reverse = false;
void set_stepper_pattern(u8 a, u8 b, u8 c, u8 d, bool reverse = false)
{ m_stepper_pattern[0] = a;
m_stepper_pattern[1] = b;
m_stepper_pattern[2] = c;
m_stepper_pattern[3] = d;
m_stepper_reverse = reverse;
}
u8 calc_pattern(u8 a, u8 b = 100);
void test() { set_stepper_pattern(0,1,2,3); }
u8 stepper_device::calc_pattern(u8 a, u8 b)
{
u8 retval = 1 << m_stepper_pattern[a];
if (b < 4) retval |= (1 << m_stepper_pattern[b]);
return retval;
}
void stepper_device::advance_phase()
{
//Standard drive table is 2,6,4,5,1,9,8,a
//NOTE: This runs through the stator patterns in such a way as to drive the reel forward (downwards from the player's view, clockwise on our rose)
//The Heber 'Pluto' controller runs this in reverse, this needs checking on real hardware
if (m_pattern == calc_pattern( 0)) m_phase = 7;
else if (m_pattern == calc_pattern(1, 0)) m_phase = 6;
else if (m_pattern == calc_pattern( 1)) m_phase = 5;
else if (m_pattern == calc_pattern(2, 1)) m_phase = 4;
else if (m_pattern == calc_pattern( 2)) m_phase = 3;
else if (m_pattern == calc_pattern(3, 2)) m_phase = 2;
else if (m_pattern == calc_pattern( 3)) m_phase = 1;
else if (m_pattern == calc_pattern(0, 3)) m_phase = 0;
else if (m_pattern == calc_pattern(0, 2))
{
if ((m_old_phase ==6)||(m_old_phase == 0)) // if the previous pattern had the drum in the northern quadrant, it will point north now
{
m_phase = 7;
}
else //otherwise it will line up due south
{
m_phase = 3;
}
}
else if (m_pattern == calc_pattern(1, 3))
{
{
if ((m_old_phase ==6)||(m_old_phase == 4)) // if the previous pattern had the drum in the eastern quadrant, it will point east now
{
m_phase = 5;
}
else //otherwise it will line up due west
{
m_phase = 1;
}
}
}
}
So by choosing a bit order, you can set the bit pattern for a given stepper and then not have to use bitswap code, as one you call set_stepper_pattern() you will have the order you need.
Just curious, did you make PRs for any of the other stuff you got working like the Commodore 4-color pen plotter and all the other Commodore printers you showed working (or mostly working) above?
I suppose there's nothing stopping me from doing stuff in my own fork. I may as well put it on github for I've got a bunch queued up, just waiting for the green light.
He can't. Printers are under the Vas Death Penalty, at least until someone makes an Adobe-compliant middle layer.
That's a real shame. So much cool stuff blocked and not only just printers. Eventually the users will rebel against the fatcats at the top of the pyramid and they'll be a good ol' hangin' lol
One possible reason is that the CE-150 rom gets bank switched out by the PV flipflop, which isn't handled by either the driver or currently exposed by the lh5801 cpu.
Poking values into 79F4 changes the size of the text.
(can't read my, can't read my poke &79F4 face)
(man, the imgur website seems to be acting really wacky for me lately)
edit: turns out there's good Basic support for the CE-150 with commands to set character size (CSIZE) to do line feeds (LF) and to switch from text to graphics (TEXT and GRAPH) as well as drawing lines (LINE), moving the pen (LCURSOR for text, GLCURSOR for graphics).
Ran across the PRT-MPF printer for the MicroProfessor 1b (mpf1b), and it looks pretty simple.
It's actually quite a simple design, the carriage moves forward and then returns while feeding the paper for a single line.
Two io addresses are used, CA and CB where one address controls the motor and the thermal head elements, and the other reads the home position and the motor "tacho generator pulse".
I managed to get it to do something that looks recognizable:
Excellent! Did you send patches to mamedev github about Commodore printer/plotters?
Does anyone make ROM dumps from Atari 1020 plotter? I have Atari 2020 field service manual (thanks for PDF link). If not, I will make ROM dumps and send them to you some day.
I made ROM dumps from NX2420 24-pin color printer and have technical manual (includes schematics). Someone sent me a copy of NX1000 multi-font ROM dumps.
I was working on MX80 emulation but ROM dump for 41A slave processor is bad (first 2 bytes were overlaid with register value). I need a good copy of 41A ROM dump. My USB EPROM programmer does not support MCS-41/48 series.
I did make a full mirror of Zimmers archive includes printer ROM dumps and manuals.
He can't. Printers are under the Vas Death Penalty, at least until someone makes an Adobe-compliant middle layer.
That's a real shame. So much cool stuff blocked and not only just printers. Eventually the users will rebel against the fatcats at the top of the pyramid and they'll be a good ol' hangin' lol
That is not nice. There are PDF function calls in Qt development package so that you can generate paper layer like bars, blank, etc. (kind of papers) then draw results on that layer. It can display results on screen as real-time and save finished page into PDF file. That should be results on background layer with holes at end sides.
For example, look at Virtual1403 on GitHub that produces PDF files with paper layer as background like bars, etc.
I gather the "death penalty" means no slot machine TITO emulation can happen for quite some time. Slot machine printers predate the modern barcoded thermal tickets too, the machines used to print out dot-matrix tickets on plain paper that you had to manually take to the cashier to convert to cash and couldn't insert back into a machine.
"You really like making things more complicated than they need to be, don’t you? Take a step back and think."
I have thought about how my life is a lot more complicated than it should be and whether it's worth it to try to get anything accepted into master.
Supposedly open source projects are about collaboration but there seems to be a desire to have everything 100% perfect before it goes in.
Sometimes perfect is the enemy of the good. (or the okay)
The bitmap printer isn't the greatest code ever, but it could easily be replaced. Once the mythical page device becomes available, there's only a few lines of code that have to be changed. (You know, like code gets changed all the time without having the "death penalty", and this dates back to late 2021)
So nothing is allowed to go in until that page device is here which is quite frustrating and deflating and discouraging.
There I've said my piece.
It's surprising how much fun it is to work on the datamaster with jlopezm who's enthusastic versus the hostility that I perceive from comments like the above.
Does anyone make ROM dumps from Atari 1020 plotter? I have Atari 2020 field service manual (thanks for PDF link). If not, I will make ROM dumps and send them to you some day. I made ROM dumps from NX2420 24-pin color printer and have technical manual (includes schematics). Someone sent me a copy of NX1000 multi-font ROM dumps. Tim
If you have stuff that isn't dumped or docs not archived get them up on archive.org or something. No one can do anything if you don't put them out there....
It's kinda fun to have both the sp400 and the ap2000 online simultaneously.
You can switch from the sp400 to the ap2000 with CONSOLE ,,,,1 CONSOLE ,,,,2 (for the ap2000)
sp400 is not in MAME master. I searched for it and found some issue and pull requests. He worked on it but stopped and removed it a month later. His pull request/issue remained opened.
I can't find sp400 firmware anywhere. I found sp400emu on GitHub but no firmware available. I opened a ticket, but he quickly closed it and replied with a link to copyright info. I gave it up. He needs to put them on archive.org instead.
There is no EPROM reader supports HD6805. I searched for it, but he removed HD6805 reader repo from GitHub.
Originally Posted by Guru
Originally Posted by Tim Stark
Does anyone make ROM dumps from Atari 1020 plotter? I have Atari 2020 field service manual (thanks for PDF link). If not, I will make ROM dumps and send them to you some day. I made ROM dumps from NX2420 24-pin color printer and have technical manual (includes schematics). Someone sent me a copy of NX1000 multi-font ROM dumps. Tim
If you have stuff that isn't dumped or docs not archived get them up on archive.org or something. No one can do anything if you don't put them out there....
Ok I will put them on archive.org, GitHub or google drive.