Prevue Guide Forums

AriX wrote:I think I might need a new Amiga keyboard - occasionally mine doesn't work and the caps lock light starts flashing. I have to shut everything off for a few minutes before it will work again.

Try just unplugging the keyboard for the few minutes and plugging it back in. If this works it's probably a fault in the keyboard (the caps lock indicates that the KB didn't pass self test) in fact I'd be very surprised if this didn't work. Unlike old PCs you can plug and unplug the keyboard at any time and everything still works (Amigas were ace). If that's the case there could be a fault with the electronics in the keyboard - maybe dry capacitor or dry joint etc, or maybe something wrong with the PSU in the Amiga itself, which is being over strained - again probably dry capacitors. I have one A2000 where you can really hear the PSU fan labour when the disk drive is in action, because the PSU is on its last legs.

Your stream is pretty cool although jerky - perhaps that's the internet once it gets over here, although as you say might be the old PC factor. Also unfortunately at the moment your "computer is not registered to sync with MobileMe". This is also what I loved about Amigas, it generally didn't bleat about errors on stuff that was supposed to be in the background! Of course our beloved Microsoft PCs are at fault for introducing the massive-centre-screen-cover-everything-else-up error message.

My simulator is of course the basis for a system that provides the top half video while sending out control codes to Amigas/Simulators to put the correct overlays across the top. Once I have implemented websockets for the P data, I guess I can remove the scrolling grid code and have a control script that directs the top what to do, at the same time as sending out the control codes to simulators/real Amigas. As I have experimented before with the control data to no real avail, I guess we'll have to hope and wait for sneak prevue source to actually get that working. If that doesn't happen soon I'll set up a test rig.

tin wrote:=Try just unplugging the keyboard for the few minutes and plugging it back in. If this works it's probably a fault in the keyboard (the caps lock indicates that the KB didn't pass self test) in fact I'd be very surprised if this didn't work. Unlike old PCs you can plug and unplug the keyboard at any time and everything still works (Amigas were ace). If that's the case there could be a fault with the electronics in the keyboard - maybe dry capacitor or dry joint etc, or maybe something wrong with the PSU in the Amiga itself, which is being over strained - again probably dry capacitors. I have one A2000 where you can really hear the PSU fan labour when the disk drive is in action, because the PSU is on its last legs.

Yeah - the issue actually started when I plugged the keyboard in and it rebooted the machine, which obviously indicates that something is wrong. From there, the light started flashing, and when I saw online that this indicated a keyboard ROM test failure, I was a bit worried. I restarted everything, unplugged/replugged, etc., but nothing worked until finally when I left everything off for 20 minutes and plugged it back in, all was fine. The keyboard has worked perfectly since.

tin wrote:Your stream is pretty cool although jerky - perhaps that's the internet once it gets over here, although as you say might be the old PC factor. Also unfortunately at the moment your "computer is not registered to sync with MobileMe". This is also what I loved about Amigas, it generally didn't bleat about errors on stuff that was supposed to be in the background! Of course our beloved Microsoft PCs are at fault for introducing the massive-centre-screen-cover-everything-else-up error message.

Haha, whoops! I remoted in and got rid of that, but it may come up again. I could build an application that just forces itself to stay over absolutely everything, kind of like how I would guess the ESQ app does it? I don't know anything about Amigas :p

tin wrote:My simulator is of course the basis for a system that provides the top half video while sending out control codes to Amigas/Simulators to put the correct overlays across the top. Once I have implemented websockets for the P data, I guess I can remove the scrolling grid code and have a control script that directs the top what to do, at the same time as sending out the control codes to simulators/real Amigas. As I have experimented before with the control data to no real avail, I guess we'll have to hope and wait for sneak prevue source to actually get that working. If that doesn't happen soon I'll set up a test rig.

I don't quite understand - what sends out control codes? Is it the JavaScript, or some PHP thing? Is it fetch or "push"?

AriX wrote:Yeah - the issue actually started when I plugged the keyboard in and it rebooted the machine, which obviously indicates that something is wrong. From there, the light started flashing, and when I saw online that this indicated a keyboard ROM test failure, I was a bit worried. I restarted everything, unplugged/replugged, etc., but nothing worked until finally when I left everything off for 20 minutes and plugged it back in, all was fine. The keyboard has worked perfectly since.

Odd! I still think it MUST be the keyboard only. Dunno what could have caused exactly what you describe there though.

AriX wrote:Haha, whoops! I remoted in and got rid of that, but it may come up again. I could build an application that just forces itself to stay over absolutely everything, kind of like how I would guess the ESQ app does it? I don't know anything about Amigas :p

Prevue will be running on it's own screen (or likely IMHO multiple screens by the looks of it) which are seperate to the workbench screen you see at boot. These are kind of equivalent to the virtual desktops you get of these days, although still not quite the same (an application can own the screen, and they can be different resolutions on screen at the same time, they're like a whole seperate hardware screen that can be addressed separately, not stuff just shifted in and out of view on a real screen). Also they can slide up and down into any position (which is why I think prevue uses several). In fairness, applications or the OS can flip a particular screen to front if they want attention, but the PG doesn't run any such applications as it starts up anyway, which is the main reason there's nothing to nag at you while PG is running.

AriX wrote:

tin wrote:My simulator is of course the basis for a system that provides the top half video while sending out control codes to Amigas/Simulators to put the correct overlays across the top. Once I have implemented websockets for the P data, I guess I can remove the scrolling grid code and have a control script that directs the top what to do, at the same time as sending out the control codes to simulators/real Amigas. As I have experimented before with the control data to no real avail, I guess we'll have to hope and wait for sneak prevue source to actually get that working. If that doesn't happen soon I'll set up a test rig.

I don't quite understand - what sends out control codes? Is it the JavaScript, or some PHP thing? Is it fetch or "push"?

I intend to write a (or expand on existing) script that sends out control codes to both PG machines (simulator or real) and the video server (= altered simulator) at the same time. The script will be push, with the simulators listening on websockets, real or emulated amiga/atari listening on serial ports. The script will co-ordinate video playout and the blanking/audio switch function of the PG machines/emulators while co-ordinating the video/audio playout of the video server. The script will be in perl and the video server in HTML5/javascript as per the current simulator.

tin wrote:Odd! I still think it MUST be the keyboard only. Dunno what could have caused exactly what you describe there though.

Yeah, you're probably right. I would think it has to do with old capacitors somewhere or something.

tin wrote:Prevue will be running on it's own screen (or likely IMHO multiple screens by the looks of it) which are seperate to the workbench screen you see at boot. These are kind of equivalent to the virtual desktops you get of these days, although still not quite the same (an application can own the screen, and they can be different resolutions on screen at the same time, they're like a whole seperate hardware screen that can be addressed separately, not stuff just shifted in and out of view on a real screen). Also they can slide up and down into any position (which is why I think prevue uses several). In fairness, applications or the OS can flip a particular screen to front if they want attention, but the PG doesn't run any such applications as it starts up anyway, which is the main reason there's nothing to nag at you while PG is running.

Oh, okay, thanks for that explanation.

tin wrote:I intend to write a (or expand on existing) script that sends out control codes to both PG machines (simulator or real) and the video server (= altered simulator) at the same time. The script will be push, with the simulators listening on websockets, real or emulated amiga/atari listening on serial ports. The script will co-ordinate video playout and the blanking/audio switch function of the PG machines/emulators while co-ordinating the video/audio playout of the video server. The script will be in perl and the video server in HTML5/javascript as per the current simulator.

Sounds cool! I'll be excited to see it. Maybe we can coordinate our efforts somehow at some point. I am almost ready to write the WebSockets integration for my sender if you're still interested.

AriX wrote:Sounds cool! I'll be excited to see it. Maybe we can coordinate our efforts somehow at some point. I am almost ready to write the WebSockets integration for my sender if you're still interested.

Definitely! I'm going to experiment with WebSockets a bit over the next few days then I will see how I can integrate WebSocket updates into the current simulator......

I was tinkering around with the streaming, and I changed it to RTSP. You'll need QuickTime or VLC or something if you want to see it. It's pretty low-res because H.264 is too much for the old PC's processor, but I'm going to be getting a newer PC in the next two days that I could run it off of.

EDIT: Nevermind.

AriX wrote:I was tinkering around with the streaming, and I changed it to RTSP. You'll need QuickTime or VLC or something if you want to see it. It's pretty low-res because H.264 is too much for the old PC's processor, but I'm going to be getting a newer PC in the next two days that I could run it off of.

[url]rtsp://home.winxblog.com/[/url]

Hmm...Tried it with Quicktime and VLC, but not able to get it working.

Bolt96 wrote:

AriX wrote:I was tinkering around with the streaming, and I changed it to RTSP. You'll need QuickTime or VLC or something if you want to see it. It's pretty low-res because H.264 is too much for the old PC's processor, but I'm going to be getting a newer PC in the next two days that I could run it off of.

[url]rtsp://home.winxblog.com/[/url]

Hmm...Tried it with Quicktime and VLC, but not able to get it working.

Yep, seems that VLC's built-in RTSP client doesn't play well over the internet. I'll mess with it some other time. I put the old one back if anyone cares - I tweaked the settings, so it may work much better than before.

AriX wrote:I'm currently playing around with my AP2000, and I've posted a video stream if want to see.

Right now, not too much interesting stuff is going on, and the feed itself isn't great. I'm almost done with the data server, so I will be testing that out a bit on here, but also at some point soon I'll be hooking up a video feed.

If the Flash stream isn't working, you can try the image stream. I think I'll be switching to the Darwin/QuickTime Streaming Server or HTTP Live Streaming instead of this.

That was pretty cool, it almost look like the Prevue Channel was making a comeback for a little while. With current trailers of upcoming movies included, along with the grid. If only we had TV spots, ads and other stuff.

AriX wrote:I'm currently playing around with my AP2000, and I've posted a video stream if want to see.

Right now, not too much interesting stuff is going on, and the feed itself isn't great. I'm almost done with the data server, so I will be testing that out a bit on here, but also at some point soon I'll be hooking up a video feed.

[html]
<object classid="clsid:D27CDB6E-AE6D-11cf-96B8-444553540000" codebase="http://download.macromedia.com/pub/shoc ... on=9,0,0,0" width="480" height="385">
<param name="movie" value="http://home.winxblog.com:86/nchplayer.s ... start=true">
<param name="allowfullscreen" value="true">
<param name="quality" value="high">
<embed src="http://home.winxblog.com:86/nchplayer.s ... start=true" width="480" height="385" allowfullscreen="true" quality="high" type="application/x-shockwave-flash" pluginspage="http://www.adobe.com/go/getflashplayer"/>
</object>
[/html]

If the Flash stream isn't working, you can try the image stream. I think I'll be switching to the Darwin/QuickTime Streaming Server or HTTP Live Streaming instead of this.

So, I wanted to make a stream of the LaserDisc, but I need to buy a serial cable specifically for the LD-V8000 in order to hook it up to my PC (or the Amiga, for that matter), and I need to hook it up to my PC in order to make it repeat (otherwise it just stops when the LaserDisc is over). So for now I just parked the LaserDisc player on a certain frame.